New Member.

User unable to login to edirectory directly

We have a single user/workstation where we had to reinstall the OES Client. It's a Windows 7 SP1 x64 with OES Client for Windows 2 SP4 IR6.

Now he doesn't log on properly ie. it seems like he logs on with "Computer Only" even though he authenticates to edirectory.
No errors.

So no automatic login to SecureLogin and Zenworks. No loginscript gets executed.

After logon he can login manually to SecureLogin, Zenworks and OES (and now the loginscript runs, so he gets the network drive mappings etc.)

I verified the computer only and credential provider registry settings are like other working machines.

I attached debuglogs.
Any ideas?

Labels (1)
3 Replies
Micro Focus Contributor
Micro Focus Contributor

Re: User unable to login to edirectory directly

mla hm <> wrote:

> I attached debuglogs.

The NCCredProvider log is suggesting that the failure to run
eDirectory login scripts or see authenticated eDirectory connections
is a secondary symptom.

And that the primary issue is that the Windows LogonUI.exe process is
crashing during the earlier login processing, such that Client for
Open Enterprise Server never gets the chance to assign the NCP
connections over to the logged-on Windows user.

There have been at least two LogonUI.exe crashes we've chased
recently, but they were on Windows 10, and were for very Windows
10-specific reasons, with fixes ultimately issued by Microsoft. Which
isn't anything that would "also be occurring" on this Windows 7

The key evidence to examine next will be the mini-dump Windows is
generating for the LogonUI.exe crash(es), which would be written under
\ProgramData\Microsoft\Windows\WER\ directories. If you wanted to
attach one of them here I can see if there are any obvious conclusions
to be made. Or if you need more urgent or guaranteed follow-up,
opening a support case would be appropriate too.

Alan Adams
Client for Open Enterprise Server
Micro Focus
New Member.

Re: User unable to login to edirectory directly

Hi Alan,

Thanks for the answer. Couldn't even see that from the log.

I have attached the mini-dump (added .txt extension to upload), but at the same time i created SR#101075848131

Micro Focus Contributor
Micro Focus Contributor

Re: User unable to login to edirectory directly

Yeah, there isn't any direct or explicit indication of "crash" from an
NCCredProvider logging perspective. What implies that a crash
occurred is that in the midst of the login-related processing, we see
a new "[NCCredProvider] log opened - 06JUN2017 11:29:56.618 Logging
on process ID 5496 (0x1578): ""LogonUI.exe" /flags:0x0"".

We expected to see "log opened" for other processes, such as
MPNOTIFY.EXE or NWTRAY.EXE, but not a new "log opened" for LogonUI.exe
without there first being a "log closed" which happens during an
orderly shutdown. So seeing a new "log opened" out of the blue is
what indicates that there was an uncontrolled termination of the
previous LogonUI.exe, and Windows had to start a new instance.

The .WER confirms that indeed LogonUI.exe is crashing, but
unfortunately the .WER is not an actual dump file. The mini-dumps
that WER captures by default can be .HDMP or .MDMP, so if you have
multiple "*logonui.exe*" directories under the WER directory area,
check whether the others have an actual dump file.

If not, the engineer on SR 101075848131 is going to follow up with
further recommendations for collecting a dump of the crashing
LogonUI.exe process.

Alan Adams
Client for Open Enterprise Server
Micro Focus
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.