Sign in to follow this  
Followers 0
pagi4

Long WinLogon init after upgrading from Windows 7

25 posts in this topic

The odd part is that once LogonUI starts, it takes upwards of 30 seconds for it to move on to loading drivers, parsing WMI providers and event logs, etc. Procmon can't really tell us what happened at the winlogon screen, but that's slightly north of 30 seconds where it appears it's spending the VAST majority of it's time talking to the audio driver for some reason (that isn't normal). Assuming you updated drivers, something is indeed wrong, but procmon probably isn't going to be verbose enough for us to figure it out given what it's showing us. Can you run the following commands to get another set of ETL trace data?

md C:\boot_trace

reg add "hklm\software\microsoft\windows\currentversion\policies\system" /t REG_DWORD /v verbosestatus /d 1 /f

xbootmgr -trace boot -verboseReadyBoot -traceFlags LATENCY+DISPATCHER+DISK_IO_INIT+NETWORKTRACE+MEMINFO+POWER+PERF_COUNTER+PRIORITY+REGISTRY+FILE_IO+FILE_IO_INIT -postBootDelay 180 -stackwalk Profile+ProcessCreate+CSwitch+ReadyThread+mark+ThreadCreate+DiskReadInit+DiskWriteInit+DiskFlushInit+RegSetValue+RegCreateKey+RegSetInformation -resultPath C:\boot_trace

After you run those commands, your box should reboot and create a working trace after logon without any errors (located in C:\boot_trace). Compress that .ETL file up and let us know when it's available and where.

0

Share this post


Link to post
Share on other sites

it's now your turn, cluberti. I have no idea.

The only thing you can try is to create a new empty account and see if it happens there, too.

0

Share this post


Link to post
Share on other sites

Well, it looks audio driver related, but looks can be deceiving. I guess we wait for an ETL file.

0

Share this post


Link to post
Share on other sites

After you run those commands, your box should reboot and create a working trace after logon without any errors (located in C:\boot_trace). Compress that .ETL file up and let us know when it's available and where.

Hello. Sorry for the delay.

Here is the trace:

https://dl.dropbox.com/u/406695/boot_trace_20121116.rar

Thanks!

0

Share this post


Link to post
Share on other sites

So, you have a few things happening here:

1. You have a 4 second delay loading your hard disk drive - no clue why, as this is a BIOS setting.

2. You have a WD Green drive, and those are notoriously poor for random disk I/O during the boot process. Nothing you can do about physics, as these drives are designed for lower power footprint at the cost of seek and load speed. There are utilities out there that can disable the head parking feature, but it won't help you during boot time (and it removes the "green" features of the drive when in use, so I wouldn't recommend it if you chose this drive for those reasons as well). Not much you can do when you use a 5900RPM drive to boot from ;).

3. Booting the base system (kernel, smss, csrss, and lsass binaries) takes approximately 20 seconds. This should normally take between 10-12 seconds, 15 at the outside, but is taking 5-7 seconds longer on your machine. This is being caused by a few things - there's a large number of volume shapshots being read after the disk is mounted (start > cleanmgr > <drive> > "clean up system files" > More Options tab). Also, there's another section of time spent loading and hashing drivers as there's a driver on the system that is a signed binary rather than containing a signed catalog - this is fine, but can cause boot delays in this phase due to causing signature verification as it cannot be found in a catalog (this is guard64.dll, by the way).

4. Comodo is blocking LSASS communication and functionality between services.exe and the security subsystem for approximately 17 seconds after winlogon starts via Comodo's guard64.dll binary. No services or programs of any kind are allowed to start until it finishes loading, which blocks LSASS being able to access the SAM, causes problems with it's ability to read the registry (which also delays SAM load), which blocks other services from starting, which all causes 17 seconds of delay in the trace you uploaded. As soon as services.exe is started and guard64.dll is loaded at 21 seconds in, everything stops until it's finished, at approximately 38 seconds into the trace. You may actually see a warning by Microsoft-Windows-Winint (event 11) being logged on your machine in the event viewer stating that the system is being hooked in all processes by a non-Microsoft .dll file - this would be that file.

5. Malwarebytes' Antimalware client is causing approximately a 30 second delay in loading Explorer.exe, even after winlogon takes an additional 19 seconds to log you in after you've provided credentials (which was after the 38 second delay in providing you a credential prompt, and the 20 seconds in just loading the bare, base system).

6. Getting your machine completely booted and idle takes another ~40 seconds due to all of the things starting with the explorer shell, like LastFM, DropBox, Comodo's apps, and a few shell extensions. Not bad, but it may still behoove you to look into trimming that perhaps, otherwise you'll have to live with that.

All in all, Comodo is a big drain on system resources and a big part of your problem, but there's also the Malwarebytes portion of the delay, and the fact that your boot drive isn't very fast. I suppose you already knew about that last part, but I'd remove MWB and Comodo from the system completely, retest, and only re-add either if you have no other options for security products.

0

Share this post


Link to post
Share on other sites

Thanks for your deep inspection of my trace and detailed answering, cluberti.

I have removed Comodo and Malwarebytes software from my OS environment and deleted all System Restore snapshots except the last one. I don't know how to get rid off hard disk pre-delay, there is no direct setting in BIOS (ASUS P8H67 motherboard). I tried to switch SATA controller working mode from IDE to AHCI but I've ended up only with the new fancy Windows 8's BSOD and boot looping. So I switched back to IDE emulation again.

Anyway, now the strange thing is happening. :ph34r:

While I'm cold booting (powering from "off" state) my PC, Windows 8 starts almost immediately. It takes nearly 5 seconds (maybe even less) after POST to show me logon screen.

But if I'm rebooting, the typical lag and the long boot time are still there anyway :unsure:

Here is xbootmgr's long reboot trace:

https://dl.dropbox.com/u/406695/boot_trace_20121117.rar

I could provide you with the cold boot trace but I don't know what parameter I should use to tell xbootmgr to perform tracing after manual shutdown.

Edited by pagi4
0

Share this post


Link to post
Share on other sites

The AudioEndpointBuilder service is still taking an inordinately long amount of time to start - while it's not broken, you still have some sort of audio driver issue - I notice it's taking a very long time for the 1394 M-Audio device to be recognized and loaded, so if you're not using the Firewire Audio interfaces, disable those in device manager. Also, guard64.dll is still hooking all process loads, so if you removed Comodo you didn't get it all and you might want to run through the uninstall process again. Also, the stisvc service (Windows Image Acquisition) takes the better part of 7 seconds to start as well, which could be due to the Firewire port probing, but more likely you have a scanner or printer attached that is delaying it's start.

You might want to check and make sure that you have enabled "Turn on fast start" as well, which does speed up shut down/reboot scenarios in Windows 8:

PowerOptions_SystemSettings_FastStart_Windows8.png

0

Share this post


Link to post
Share on other sites

I removed audio card driver, disconnected it from PC and disabled 1394 controller in Device Manager. Disabled stisvc service (I don't use scanning via WIA anyway).

Reinstalled and removed COMODO once again but after reboot there is still the lag. Is there a way to stop hooking manually? By the way, I can't find guard64.dll file in C:\Windows\system32\.

Thanks for the "fast startup" tip, it's already on and it's describes why the system loads so faster after cold booting.

UPD:

I deleted "C:\Windows\system32\guard64.dll" string in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs" parameter and switched "LoadAppInit_DLLs" to 0 but it gave no effect.

I wish I was able to perform fresh installation of my Windows copy... :rolleyes: Unfortunately, I have really massive amount of software and its plugins to install again which is huge waste of time comparing to my waiting of system boot. :ph34r:

Edited by pagi4
0

Share this post


Link to post
Share on other sites

So, I guess, there is no way to stop this lag. :unsure:

0

Share this post


Link to post
Share on other sites

Given the behavior, it just seems like a botched upgrade - an "almost worked" one somehow. It happens, unfortunately.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.