Jump to content

cluberti

Patron
  • Posts

    11,045
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    country-ZZ

Posts posted by cluberti

  1. Windows 8 will let you connect to as many networks as you have devices for, but it's only going to use one *long term*. It will disable any it isn't using within a short time, as connections that may be active on it get FIN'd (or some other disconnect, of course. There can be a decent amount of time where multiple connections are active, though.

  2. There are some caveats here to be aware of, although I'm not sure they apply here. I'll throw them out there just in case someone else runs across this - if there are problems with the boot.wim loading fonts on the PXE server, this is actually the behavior that would occur (no video after the "loading" starts). You can run into this if you upgrade from an RC build to an RTM build of the product (Server 2012 in this case, although it'd probably affect 2008R2 and 2008 as well), if you manually copy the boot.wim into RemoteInstall instead of using the UI or wdsutil to do it, and it could also happen if you somehow got RC or beta code into the RemoteInstall folder, even if you're currently using RTM code at the time it occurs.

    The recommendation would always be to rebuild the server cleanly, rebuild the PE image from a known-good ADK installed source, and try again. If the problem still persists after doing everything right, then the recommendation is always to engage Microsoft to see what is happening at that point.

    Again, after talking to Trip this is an RTM install of Server 2012 with an image that seems to work on other UEFI systems from this server without issue, but I figured I'd throw this blurb out there just in case someone comes across this in the future.

  3. http://www.microsoft.com/oem/en/licensing/sblicensing/pages/downgrade_rights.aspx#fbid=nUzWaeiC80x

    Might want to rethink those dates and read carefully the rights under downgrade rights and to what OS versions you have rights to download, and from where. And no, there will be no XP updates provided after April 2014 unless you belong to an organization that has a premier support contract and a volume licensing agreement with software assurance, and purchase above and beyond those a custom support agreement for Windows XP. And that will be expensive, for obvious reasons.

  4. If you want to remove inbox components (like IE6 on XP), you have to use tools like nLite. IE is, in and of itself, not an uninstallable component. You can upgrade it (for example, IE8 on XP from IE6), and you can remove said upgrades, but removing the browser is not natively possible. There are tools (like nLite) available to remove components, but those carry with them the risks of potentially breaking your installation if you go too far, of course.

  5. 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

  6. Well, this is very, very odd. BrYNSync.exe is continuously making calls through services.exe to the print spooler. It appears this is some sort of Brother printer service, talking to a .dll on the system, which is continuously calling some function I don't understand. However, I can tell that at the beginning of the shutdown trace, it appears that the thread this service is running goes into the advapi32!ScSvcctrlThreadW function, which calls a service's ServiceMain (startup) routine. It then enters into doing some functions in the BrMonitor.dll driver, which I don't have symbols for (Microsoft makes their symbols for most products public, so we can debug, but the Brother symbols are not so it's a black box right now). This appears to take almost all of the 500 second delay here, and when that stops, the box continues shutting down properly.

    Have you updated any drivers, or installed anything new before this happened? In the very least, it seems like the Brother printer software on the machine is causing you problems here, but again, I have no idea why. There's no way to dig further in this trace, but without all the Avast spam in the logs it becomes quite obvious the printer driver has a service, and that service is refusing to shut down properly or in a timely manner.

  7. 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.

  8. Well, Andre is right - you've got a ton of disk I/O, some of it taking upwards of 6 SECONDS to call by CLFS.sys (common log file system), which is causing the delay (it's going to disk 8, but a shutdown trace doesn't always store drive letters unfortunately). There's definitely an Avast component here, and it looks like it's trying to use the CLFS driver to write to something and can't. However, there's no callstack data here (either -stackwalk wasn't used as part of the trace command, or disablepagingexecutive wasn't set properly before rebooting and tracing), so I can't tell you any more than that with this trace. However, I'd put a greenback on it not reproducing without Avast installed (and why they're still using CLFS for logfile commands on a Vista or newer system is a little beyond me, but that's a different discussion altogether). The reason being I did do an analysis of the In/Out switches via Wait Analysis and found that the vast majority of the waiting time is being spent by the Avast driver waiting on other functions in the Avast driver - more than 50% of the time in just that section of the trace. That's a really, really high number from experience, and points to a potential bug in their code (for whatever reason, I couldn't tell you, as again I have no further debugging ability here with these trace flags).

    I'd remove (not disable) Avast, reboot, and then reboot a second time before doing a comparison shutdown.

  9. 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.

×
×
  • Create New...