[Win10] Random Logon Problems - for anyone that likes a challenge

[timbo343]

We need some more heads to look at this issue we have as we are struggling to pin it down.

 

We have 191 computers over 6 ICT suites. Using impero to log them all on we see a few (max 10 random machines) throw up a CMD error:

 

The application was unable to start correctly (0xc0000018). Click OK to close the application

 

The start menu and task bar aren't use able and the only way to get round this is to power off the machine and then the machine will work as if there were no errors.

 

Some of the things we've tried and some background on how this user is logging on:

 

 

-> This user is a domain admin and doesnt have a profile, therefore the profile is local to the machine.

-> We used to get error 0xc0000142, now getting 0xc0000018.

-> We've change the registry entry at HKLM\Software\Microsoft\WindowsNT\Current Version\Windows - LoadAppInit_DLLs from 1 to 0 and at location HKLM\Software\WOW6432Node\Microsoft\WindowsNT\Current Version\Windows.

-> We've removed the registry entry at HKLM\Software\Microsoft\WindowsNT\Current Version\Windows - AppInit_DLLs and at HKLM\Software\WOW6432Node\Microsoft\WindowsNT\Current Version\Windows.

-> We've tried changing the permissions on the registry entries that match the DCOM errors. These are either CLSID or AppId Keys.

-> We've tried changing the permissions on the DCOMs.

-> There's nothing out the ordinary in schedule tasks.

-> There's nothing out the ordinary in Startup (MSConfig).

-> Machines are patched up to the latest CU.

 

 

This is what we see in the event viewer of the machines that have an error:

 

Application popup: cmd.exe - Application Error : The application was unable to start correctly (0xc0000018). Click OK to close the application.

 

The server {CA8C87C1-929D-45BA-94DB-EF8E6CB346AD} did not register with DCOM within the required timeout.

 

The server {D63B10C5-BB46-4990-A94F-E40B9D520160} did not register with DCOM within the required timeout.

 

The server {D63B10C5-BB46-4990-A94F-E40B9D520160} did not register with DCOM within the required timeout.

 

 

 

 

 

 

 

This error is at log off and show on every machine, not just the machines that have the issue:

 

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

{D63B10C5-BB46-4990-A94F-E40B9D520160}

and APPID

{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}

to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool

 

I've tried the suggestions to the above error which are posted on the net, again configured via Group Policy but nothing seems to be having an affect.

 

On saying this, we have a machine in the hall which has Impero V5.4.38 and Sophos installed with no Group Policies applied to it and had the error once. The error is so random that we cannot pin point it to a machine.

 

The next thought is to test a fresh windows 10 image with no software installed baring Impero and see what this does.

 

Here are some screenshots of whats happening:

 

Logging into the machines with no Group Policies applied to them:

 

 

Errors on 2 machines:

 

The Error:

 

Difference between a non working machine and a working machine

 

When running task manager and clicking File > Run, browse to C:\Windows\System32 we see the run box doesnt show all the EXEs but yet if we were to use File Explorer to browse to C:\windows\system32 on the same machine we can see all the EXEs.

 

If anyone has any suggestions please let us know.

 

I've just got one of my techs to try it a room of 31 machines and here's the results:

 

Test 1: 2 machines (machines: 18, 22)

Test 2: 1 different machine (machine: 10)

Test 3: All machines on - no errors

Test 4: 1 different machine (machine: 27)

Test 5: 1 different machine (machine: 3)

Test 6: All machines on - no errors

Test 7: 1 different machine (machine: 12)

Test 8: 1 different machine (machine: 03)

Test 9: 1 different machine (machine: 06)

Test 10: 1 different machine (machine: 20)

Test 11: All machines on - no errors

Test 12: All Machines on - no errors

Test 13: 1 different machine (machine: 23)

 

In a different room:

 

Test 1: 1 machine (machine 09)

Test 2: 4 machines (machines 02, 12, 16, 20)

Test 3: 1 machine (machine 19)

Test 4: All working

Test 5: 1 machine (machine 14)

Test 6: 1 Machine (machine 06)

 

There's no pattern to it.

Edited May 5, 2017 by timbo343

[beany1]

Is it something to do with PaperCut?

 

I'm like 37% sure I've seen this before when PaperCut failed to load... But I could be wrong!

[timbo343]

Nope, its not papercut - thought it might be that too but the error happens on machines that have no group policy applied to it and we roll out papercut via group policy at logon. The machine in the main hall doesnt have group policy on it nor papercut. Edited May 5, 2017 by timbo343

[sccmlouis]

Have you tested any machines that don't have Impero on?

[timbo343]

Have you tested any machines that don't have Impero on?

 

No not yet, its one thing we've been wanting to try but we'd have to log each on one individually which is time consuming unless someone knows of a way to remotely log machines on.

[sccmlouis]

Best way would be to make a script to log them on and then use psexec to execute this on a room of computers I would have thought.

[timbo343]

I've thought of another way, via Registry so im going to set the 3 registry entries to REPLACE so when the GPO is removed, the policy will stop applying.

[alfatec]

Hey Timbo, I have a script that will login a full suite of computers with either the same user or different users. PM me at [email protected] for details.

[timbo343]

So we've removed Impero from a room of 20 machines - we didnt know if there was an easier way to remove impero so we had to visit each machine in turn - what a drag!

 

Before removing we tried a number of logins both with the batch login and manually inputting the username and password at each station. We still had machines erroring doing it this way. We also found out that only Impero could shut the errored machines down, the software we were using - Free Windows Admin Tools, wouldn't shut the machine down - it was almost like something had stopped the machine from been accessible.

 

We removed Impero from these machines, restarted them then visited each machine to login with the domain admin account. We tried this 6 times, and each time they all logged on without any problems.

 

Test 1 - 6: All OK, no errors and restarted machines with Free Windows Admin Tools

 

We then installed impero back on the machines and here's what we found:

 

Test 7: All Ok, restarted machines with Free Windows Admin Tools

 

Test 8: 2 Machines failed: 13 & 17

 

Test 9: 2 Machines failed: 7 & 19

 

Test 10: 1 Machine Failed: 13

 

Test 11: All ok, no errors

 

Test 12: All Ok, No errors

 

Test 13: 1 machine failed: 10

 

Test 14: 1 machine failed: 19

 

Test 15: 1 Machine failed: 3

 

Test 16: 3 Machines Failed: 9, 16, 18 - 18 was a freshly imaged machine as there's been a problem with installing 6.0.45 over 5.4.38. We've had to re-image a few machines as we kept getting the check ImperoClientSVC message. Uninstalling impero and reinstalling didnt have any affect, so Computer 18 had just had impero installed on it, restarted the machine and installed with domain admin... and it errored. Surely this points to Impero with all the tests we've done!

 

We found that login times were a little slower too with impero installed. They seemed a lot quicker when impero wasn't installed on the machines.

 

@Mic_Impero: i was wondering if you could shed any light on this topic please?

Edited May 5, 2017 by timbo343

[timbo343]

We may have found the culprit.. Impero

 

 

It seems a coincidence that as soon as we remove impero the machines behave themselves and when we put impero back on the problem re-occurs.

[NB9457]

We are having similar issues!

[sccmlouis]

Very interesting. - Impero have said that Impero 6.1 resolves the issue - unsure what else that might bring!

 

(Not yet released)

[timbo343]

So, for us, upgrading to 6.0.76 has cured the issue, thanks for Impero Support for asking so swiftly on this.

 

We've tested the test room with 31 machines and can confirm that after 8 tests with restarting all the machines, none of them gave the error.

[alfatec]

So is 6.0.76 out or still in beta?

[timbo343]

So is 6.0.76 out or still in beta?

Im not too sure but ask for it. Was also told a new full version is due out in a few days.