The Case of the Slow Logons

Update:  The Active Directory team has released useful guides for troubleshooting slow logon issues:

Emails containing troubleshooting cases keep arriving in my inbox. I’ve received many cases that start with a seemingly unsolvable problem and end a few steps later with a solution or – often just as useful – a workaround. I’ve amassed several hundred such cases that I’ve captured in over 400 PowerPoint slides, giving me great material from which to draw for my blog and the Case of the Unexplained talk series I’ve delivered at a number of major industry conferences

I’m always looking for fresh cases, use of obscure tool features, and unique troubleshooting techniques, so please keep them coming. This time, I’m sharing a fascinating case that highlights two useful techniques: comparing Sysinternals Process Monitor logs from working and problematic systems, and using Sysinternals PsExec to capture activity during a logon.

The case begins when a systems administrator at a large company got multiple end-user complaints that logon was taking over three minutes. The users didn’t encounter any problems once logged on, but the delays were understandably frustrating. Many other users running with the same software configuration weren’t experiencing issues, however. Looking for commonalities, the administrator queried the network configuration database and, sure enough, saw that all the systems with complaints were Dell Precision 670 workstations. He thought he had a major clue until he looked he saw that the systems running without issue included seemingly identical 670 workstations.

Looking for clues more directly, his next step was to try to analyze the logon process of the delayed systems. He used PsExec to run Process Explorer in the Local System account so that it would survive a logoff and be active at the next logon. Because the systems were running Windows XP, the command-line he used was the following (see the end of the post for how to do this on Windows Vista and higher):

psexec –sid c:\sysint\procexp.exe

The “-s” directs PsExec to launch the process in the Local System account, “–i” to connect the process with the interactive desktop so that its windows are visible, and “-d” to return immediately instead of waiting for the process to terminate. Note that if you have Fast User Switching enabled and you are not logged into session 0, do not log out, but instead switch users, login to the problematic account, and then switch back to the session from which you started PsExec.

At the subsequent logon, he noticed that Lisa_client_7.0.0.0.exe, the company’s own system inventory line-of-business (LoB) application, consumed CPU for a short time, went idle for three minutes, then exited, after which the logon process would continue as normal:


David Solomon coined a phrase back before Process Monitor replaced Filemon and Regmon that still applies when updated: “When in doubt, run Process Monitor!” (I follow this advice religiously, even having my daughter run Process Monitor when she comes to me with a homework question). This case is a great example of that philosophy put into practice because it seems unlikely on the surface that Process Monitor would reveal the cause for a process hang, but the administrator turned to the tool nonetheless.

After launching Process Monitor with PsExec and capturing a logon trace, he scrolled to the beginning of the captured data and started his analysis. Because of what he saw in Process Explorer, the Lisa_client process was the obvious suspect, so he right-clicked on its process name in one of the trace lines and selected the Include quick-filter menu item to remove from the display entries related to activity from other processes:


When troubleshooting a hang with Process Monitor, you should first see if there are any gaps in operation time stamps that match the hang duration. You can look for lengthy operations by adding the Duration column to the display and then making sure to filter out operations that commonly don’t immediately complete, like directory change notifications. That can be useful when you don’t see a significant time gap between operations because the process has multiple threads, some of which continue to operate while the one causing the hang is dormant.

To his pleasant surprise, he soon found an event that not only preceded a gap of exactly three minutes, but that had an unusual result code, IO DEVICE ERROR:


It appeared that the Lisa_client process performed a SCSI pass-through command to the disk hosting the C: volume that timed-out after three minutes with a hardware error. Wondering what the result of the command was on one of the 670’s that logged on promptly, he captured a trace from one and saw that the corresponding operation took less than a millisecond and was successful:


The evidence clearly pointed at a hardware issue with the disks installed on a subset of the 670’s, so he gathered disk type data from all the 670’s, correlated them with the reports of slow logons, and found that all of the slow systems had Seagate disks and the others had Fujitsu disks.

His company was obviously not going to replace disks just to avoid an issue being caused by its own LoB application, so he had to figure out a workaround. He notified the Lisa_client development team of the issue, who reported that they could remove the command without loss of functionality, but that it would take at least several days for the update to go through their internal release process. Having a few days where system information wouldn’t be collected for a subset of systems was less important than end-user productivity, so in the meantime he wrote a WMI logon script to query the system disk and launch Lisa_client only if it wasn’t a Seagate model.

Without Process Monitor’s help he would have probably determined that the disks were the key hardware difference, but it’s not clear he would have discovered the root cause and been able to work around it rather than resort to replacing disks. This is yet another case solved with the help of Process Monitor and insightful detective work.

In closing, I mentioned that I would provide steps for configuring an application to survive logoff and logon on Windows Vista, Windows Server 2008 and higher. The PsExec command I supplied for Windows XP won’t work on newer operating systems because Windows Vista introduced Session 0 Isolation, requiring a couple of extra commands to make the launched application accessible after a logon. First, start the utility in session 0 with this PsExec command in an elevated command prompt:

psexec –sd –i 0 c:\sysint\procmon.exe

You’ll see a window titled “Interactive services dialog detection” flash in the taskbar, indicating that a process is running with a window on the hidden session 0 desktop. Click on the taskbar window to restore the notification dialog and then on the Show Me the Message button to switch to that desktop:


The utility you launched will be visible there and you can configure it with desired settings (it’s running in the Local System account so won’t have your own account’s defaults). When done, click on the Return button to get back to the main desktop. You can now logoff and log back on to reproduce the problem you’re investigating. After logging on again, execute the following commands in an elevated command prompt to cause the doorway to the session 0 desktop to reappear:

net stop ui0detect
net start ui0detect

Go back to the session 0 desktop to look at the captured information and close the tool.

One last thing I want to leave you with is a reminder that I’ve documented many other troubleshooting cases in this blog and you can find them in the blog index here. You can also watch recordings of my Case of the Unexplained sessions from TechEd here and be sure to come to TechEd US this June in New Orleans, where I’ll be delivering it again with all new cases.

Comments (67)

  1. Anonymous says:

    Thanks for interesting article! Seems relevant to my problem of random (but quite often) slow logons between 3 and 3,5 minutes on XP SP3 computers in a domain (No FUS).

    However, like Chris and others I don’t understand how to make the monitoring tools to survive logoff!

    So please tell us exactly; how do we open the Process Explorer / Process Monitor AFTER logoff/new logon with the information from the logogg /new logon process still intact???

    A complete step-by-step list may do the trick for the less intelligent among us :o)

  2. @skatterbrainz


    Thanks for the feedback! I’m glad to hear the you find the blog interesting and useful.

  3. @gkeramidas: "select a solid color for the desktop, in personalize/desktop ackgound/solid colors. logon time will go from 2 or 3 seconds to at least 30 seconds. choosing a picture will restore the 2 second logon time."

    This is a known bug and there is a hotfiy available:

  4. @Mr. Slow Logon

    Thanks for the feedback. Sounds like you have an interesting case. One way to capture a procmon trace is to configure it to generate a log at next boot (options->enable boot logging).

  5. It captures until you run the GUI or shut down the system.

    Post the log somewhere so that others can take a look.

  6. Anonymous says:

    Hi All,

    I’ve been trying to figure out why it’s taking my machine 5 minutes to logon off domain and quite a few more on domain. I have a very fast SSD 840 PRO which is doing 500+ megs a second.

    I’ve tried following this blog but what got me was how he knew what was causing the slow down.

    Here’s a pic of my processmon capture which shows anything that was longer than 2 seconds.…/slow.jpg

    Any help understanding why in this case everything is going slow would be helpful.

    I’ve disabled the netbios search on all 5 of my network adapters which have IPV4 and I believe that will net me 25 seconds back after reading some other posts which claim it’s taking 5 seconds to time out on each. Secondly, I disabled windows search indexer
    temporary to see if that is also causing the problem.

  7. Geemail_1 says:

    @Juniper’s Fault

    Sounds like we may be experiencing different issues.  As long as our laptops never hit the VPN, the logon times,while not lighting fast, are not significant.  Once they connect VPN and come back to the physical domain connection, the first logon of the day is delayed.  Subsequent logons during the same day are normal.

    To Mark and the rest of the group:

    I ran ProcMon and Enabled Boot Logging on a laptop which had been off the physical network for approx. 10 days.  During those 10 days, it connected via VPN.  The ProcMon capture is approx. 900MB.  I have applied a filter as suggested by Stephan on his Friday, January 22, 2010 12:38 AM posting.  This takes the capture down to 7.6 MB.  I have reviewed the capture over and over but I am not finding where the delay is residing.  I was wondering if there is anywhere I can upload the filtered capture to be reviewed or if anyone can provide any suggestions of how to begin eliminating certains events.


  8. @Dan

    Actually, PsService is the tool you really should use 🙂

  9. @gcubed, pheel, chris, bluegene:

    Can you please provide a detailed description of the steps you’re following and are you using Fast User Switching (FUS – I updated the post to address FUS scenarios)?

  10. Anonymous says:

    i’ll let you know about another cause of slow logons in windows 7.

    all you have to do is select a solid color for the desktop, in personalize/desktop backgound/solid colors.

    logon time will go from 2 or 3 seconds to at least 30 seconds. choosing a picture will restore the 2 second logon time.

    i took one of the pictures and edited it, making it a solid color, that’s how i got around the issue.

    seems strange, but it’s completely reproducible.

  11. Anonymous says:

    Oh Mark Russinovich, where art thou..?

    Your followers still needs some answer, as you can see..  :o)

  12. mk says:

    Hi Mark,

    Cool post. Your blog is great! Thanks alot for sharing 😀

  13. Ethan T says:

    First, I’ve had slow logon problems on multiple computers, and this is the first time I’ve seen a truly helpful debugging process. The mere command line "psexec -sid" puts me in Nerdvana. Knowing that trick, I might have figured out the subsequent procexp and procmon steps, but it’s great to have it all laid out. Now I’ve got to go fix two friends’ laptops that take forever to log in!

    BTW, every time your blog appears with a new post in my RSS reader, I eagerly give it my full attention. Every post is pure gold. Keep up the great work, Mark.

  14. Pheel says:

    "psexec –sid c:sysintprocexp.exe" does not survive a logoff-logon on xp. What am I doing wrong?

  15. Dale says:

    Sad fact is Mark, was that I was a Vista TAP tester for that company, and I called out that the Lisa client was not Vista compatible.

    (I was also the regional support guy for that tool as well).

    "Vista compatibility is on the Lisa roadmap!" the dev team told me.

    Looks like it never happened.

  16. Malakai says:

    Yu’re the boss Mark. All your post are really great, I’m learning (and sure I will learn) a lot with this.

    Thanks for it!

  17. miro says:

    not 100 % sure but i think this case was already included in one of the "case of unexplained" videos located on

  18. John says:

    Excellent article!!!! Will use this to debug my logon delays at my PC.

    Thanks Mark!

  19. Chris says:

    I’m using Windows XP and I’d like to view analyze a login, but I’m a bit lost.  Here is what I understand to do…

    1) From the command line, go to the folder where you have sysinternals suite extracted to.

    2) psexec –sid C:sysinternalsprocexp.exe

    3) accept the EULA

    4) log off

    5) what do I do next??  how do you view the data after logging back in.

  20. Bluegene says:

    Having the same problem as Pheel & Chris. doesn’t seem to work on Windows XP

  21. Tim! says:

    @Dale: the problem was a bad interaction between their internal software and a particular brand of hard drives, on XP.  Vista compatibility is utterly irrelevant.

  22. skatterbrainz says:

    I agree with ethanT above.  Keep up the great work!  Your stories and insight help hundreds, maybe thousands of IT folks around the world.

  23. MarkS says:

    Mark, could these tools be used to troubleshoot another startup issue. I intermittently get a situation where after logging into the Win2k3 domain, the XP client will hang at "Applying personal settings." Can ping the PC from another PC and even check eventvwr remotely but never get the desktop proper. Only solution is the cold-boot and log in again which always works. Seems to occur on notebooks that connect to different networks.

  24. Vaxman2 says:

    There is a hotfix available for the Windows 7 solid color wallpaper problem. KB977346

  25. John says:

    MarkS — I’ve seen the hanging at applying personal settings too. After several weeks with MS Premier support we never got it resolved.  We couldn’t get it to happen consistently enough to get a kernel dump or attach the kernel debugger.    

  26. gcubed says:

    Same problem as Pheel, Chris and Bluegene (WinXP SP2). When I log back in, no process explorer! Any thoughts?

    Thank you.

  27. sana says:

    Mark, you definitely should write posts more often. They’re fantastic!

    And let me say that videos do not replace a good writing.

  28. Chris says:

    Sure.  Thanks for the response.  We don’t have FUS enabled.  We have Windows XP SP2, connected to a domain. Running as a user with admin rights.  The systems run Symantec EndPoint Protection 11.0.

    1) psexec –sid C:sysinternalsprocexp.exe.  

    2) Accept the EULA

    3) Process Explorer GUI comes up

    4) I leave it running, log off

    5) Log back on as the same user.  Look in Task Manager, and select "show processes from all users".  Sort by System, don’t see procexp.exe, then sort by image name still don’t see it.

    6) I’m not sure the steps we are supposed to follow after this any how.  Does the GUI normally show back up?  Do I need to launch procexp.exe manually?

  29. Earl Kubaskie says:

    Wow, Mark, you don’t post all that often, but when you do, it’s time to learn something! Thanks…

  30. Patrick Hoban says:

    Another excellent post. I also had an interesting experience with slow logons & file access. I’m typing it up & will send it to Mark. I’ll include it on my blog as well.

  31. John Dangerbrooks says:

    Hmmm… I wonder what was wrong with Seagate disks…

  32. Mr. Slow Logon says:


    Excellent post as usual….I followed as many of your posts as possible regarding the utilization of procexp and procmon to troubleshoot slow logons and system hangs.  Additionally, used netmon to attempt a trap of the logon events as well.

    If time permits, please consider my quandry.

    Windows 2003 domain…Windows XP SP2 and SP3 clients….we have experienced consistent slow logon with our laptop users for quite some time.  My efforts to troubleshoot have identified a few items contributing but not the silver bullet.  Our laptop users experience over 3 minute logons on the first logon of the day.  The subsequent same day logons are not lightening fast, but considerably better than the first logon, usually by over a minute.  I have done my best to use all the tools you have provided, as well as a few others…but to no resolve.  Side note, the same units loaded with Vista and Windows 7 have less than 1 minute logon times.

    The laptops are used in the office, then taken home and used offline and subsequently to connect via VPN.  Then, when arriving back to the office, the first logon of the day takes over 3 minutes.  Logging on to a usable desktop without being connected to the network generally takes around 30-45 seconds.  No roaming profile, no logon scripts.  We do utilize group policies and throughout testing I have removed group memberships and even denied the application of group policies to individual user and computer accounts during troubleshooting attempts.  Identified 30 seconds of logon time is attributed to the fact each users has a Home Folder mapping via their user account to a Z: drive totheir local network share.  Turning off the home folder increases logon time by approximating 30 seconds but I still remain with 2 1/2 minutes of logon time in the best case scenarios.  The old and slower laptops generally fall into the 3 minute or more range without the home folder mapping.

    As I am desperate, I am now trying to consider if there is a DNS issue with the laptop roaming between home and office networks.  

    Would truly appreciate your thoughts and/or recommmendation for resolving as this has been on my "unsolvable" plate for quite some time.

    Is there any way to run ProcMon via a local script so I can capture the logon events on the first boot of the day?

    Thanks in advance for your invaluable wisdom…

  33. Mr. Slow Logon says:


    I apologize…you are correct and I do recall having enabled boot logging in the past but it does not seem to be catching the source of the of the delay…does procmon capture everything past the CTRL+ALT+DELETE screen?

    Again, thanks for the response…I have to admit, If I can’t figure this out by using the SysInternals tools and following your articles and methods….then I don’t feel like it can be figured out.

  34. Mr. Slow Logon says:

    Perfect….I will take a unit home, connect vpn, disconnect vpn, enable boot logging, leave the unit on and bring it back to the office and connect to the domain to insure the unit exhibits the first logon of the day delayed logon behaviour and save the captured events and then post.

    Anywhere specific you would recommend to post for review?

  35. Gabriel says:

    Very useful post Mark!  Thanks for sharing these great troubleshooting lessons with us.  

    One note I wanted to add.  I am running Windows 7 Enterprise and when I ran psexec –sd –i 0 c:sysintprocmon.exe from an elevated command prompt I never saw the

    “Interactive services dialog detection” prompt.  I was puzzled as I was following your instructions, but then I noticed that the ui0detect service was not yet running on my machine, once I started the ui0detect service the prompt appeared exactly as you stated.

  36. Dan_IT says:

    Psst… net start/stop is a legacy command from WINDOWS FOR WORKGROUPS… I recommend telling everyone to use sc start/stop instead. 🙂

    Except sc won’t take display names and net will… another legacy compatibility quirk that is actually quite useful.  sc needs it. 🙁

  37. Chris Hutchcroft says:

    A great post and a very useful troubleshooting method.

    A take-away is that don’t try to fix a vendor’s application, see if you can get them to fix it once the issue is identified.  That of course doesn’t prevent one from implementing a work-around in the meantime.

  38. Mr. Slow Logon says:


    Is it possible to modifyreplace specific contents of a log file for security purposes?

    I have a logfile to post for review but feel it is probably in my best interest to replace log entries containing our domain and company name with a generic name.  I can export as a CSV but that removes the capability to utilize the ProcMon filtering of events.

  39. Mr. Slow Logon says:

    I have posted a filtered logfile export to the SysInternals Forum

    The first logon of the day was over 26 minutes and the resulting capture over 3.7 GB.  I applied a filter to include any process with duration more than 30.0

    Winlogon.exe at one point shows a duration of over 1589.  

    Thoughts on how I can determine what is happening?

  40. stefang says:

    The filter you applied only includes requests that take more than 30 seconds. The only requests that take so long are requests that block while waiting for something to happen, like NotifyChangeDirectory.

    It is quite normal for a NotifyChangeDirectory to take a very long time – it actually just represents the time between modifications to the monitored directory.

    To get a useful logfile you need to apply a different kind of filter. Try filtering on time of day so you only get events from the actual boot.

    However, even with the very limited information you posted I see that you have MacAfee antivirus running. My psychic debugging powers tells me that the antivrus is probably the reason for the delay. I suspect that for some reason the antivrus is performing an antivirus scan (or perhaps an update) of the computer which causes the slow login.

    Try uninstalling the antivirus and see if it helps. If it does, it is time to talk to MacAfee support.

  41. John D says:

    To clarify – "psexec –sid app.exe" – only console applications will survive full logoff this way.

    GUI apps still get terminated – Switch Users have to be used..

  42. Mr. Slow Logon says:


    1.  The actual boot time took over 26 minutes…from power on to usable desktop…knowing I couldn’t include a 3.7gb log, I decided to filter on anything whose duration took longer than 30 seconds.  I guess I am misunderstanding what Duration really means….I assumed if something took 180 seconds duration to complete, then that would be way to long for any process.

    2.  Your debugging powers are correct about McAfee, it does wear on the logon process but I have previously removed it and tested but continue to have what I consider to be an extensive delay when a machine hits the network the first time of the day after having been offsite and using VPN.  The second boot of the day is more "normal" considering all of the items we have going on.  Example, first boot of the day(only after having been offsite using VPN), is around 4-5 minutes.  Second, third, etc boots are around 2 minutes.

    I am not expecting a 20-30 second logon…but I would like to see it around no more than 2 minutes

    Let me get a first boot of the day log file and then filter it down and post it.  Can you recommend how I can filter down everything that happens from CTRL ATL DEL to the point when it first displays the windows desktop?

    Thanks in advance for the reply….the forum had over 80 reads…no replies.

  43. stefang says:

    To get a more useful file you could use a filter like this:

    May I also suggest that you look at the Process Activity Summary on the Tools menu. It shows you what processes where active at different points in time during the capture.

    It should give you a good idea of what process was working for  20 minutes during your logon.

  44. Mr. Slow Logon says:

    Thank you….let me follow your advice and I will let you know what I come up with.

    Thanks again for following through with me on this….I have been searching for an answer for a very long time.

  45. Chris128 says:

    Thanks for yet another useful blog post Mark – I will certainly be referring to this next time I get a complaint of logons taking too long (which happens all too often)


  46. WaseeM says:

    Hello Mike

    Faced the problem of today spoolsv file of the printer, which is that the process was consuming CPU power fully and found the solution

    But I want you to work analysis of the problem

    If your time allows it

    Thank you

  47. vmagana says:


    Another great post. Thank you!

    Will you be coming to Dubai this March for TechED Middle-East?

  48. John Reilly, III says:

    Excellent post Mark, I have been experiencing this primarily on our XP SP3 clients connected to a 2003 TS Server.  The time between the login and the actual desktop appearing on the screen is 10-15 minutes.  How would Procmon be used on the TS Server to view processes from the TS users with delayed logins?

  49. Andy Helsby says:

    It looks like there is some confusion. The beginning of the article (including the command line) talks about procexp but the rest of the article is using procmon. Procmon has the ability to log and filter etc, procexp doesn’t.

  50. Michael Mansell says:

    I am a little confused.  The problem appears to be related to a domain based logon issue, although this is not stipulated.

    Perhaps I have missed something, but if a Windows XP system is "joined" to a windows domain, the ability for Fast User Switching is disabled and not accessible.

    Can this be enabled, or is this procedure only applicable to systems configured in a workgroup and not a domain?

    Otherwise an excellent article and application of these excellent utilities.

  51. Chris128 says:

    OK so this is good for capturing info when logging ON but I’ve currently got a user with a problem logging OFF – each time they try to log off or shut down the system gets as far as the "Logging Off" stage and never gets any further. It doesnt crash or freeze, just sits there on Logging Off forever (Windows XP, SP3). It even happens in Safe Mode!

    So I’m thinking I can use this trick of running Process Monitor under the Local System account and have it log activity during the log off, to try to get some more information. However I have just tested this on a virtual XP workstation and simulated the problem by just stopping the VM when it gets to the Logging Off stage (as we have to just power the laptop off and reboot it once it has got stuck on Logging Off) but when I boot the VM back up to look at the Process Monitor log file I cant open the file because it says "The file xxxxx.PML was not closed cleanly during capture and is corrupt". Is there any way I can view the captured information or any better way of doing this? One alternative I am considering is using Process Explorer’s ‘Replace Task Manager’ option and then trying to start that when the machine is in the Logging Off state (as I can still start Task Manager at that point).

    PS sorry for cluttering up your blog comments with a request for help, it just seemed very related to this topic. I’ll post the problem on the Sysinternals forum if people think thats a better idea (already posted it on technet forums a few days ago but not got much help yet)



  52. Chris128 says:

    For anyone that’s interested, I resolved our logging off problem (mentioned in the comment above)… by uninstalling .NET Framework 1.0!

    I fired up Process Explorer when the machine was stuck in the Logging Off state and that showed me that the winlogon.exe process was tagged as a .NET process (highlighted in yellow) so I thought I would see what happened if I took .NET off completely and voila, the laptop shut down without a problem as soon as I took it off. Luckily the user does not need .NET 1.0 any more so problem solved.

  53. Alan Miller says:

    For the folks with slow initial logins, I have two possibly-silly questions: Are Offline Files enabled? And is CSCdll.dll (offline network agent) doing something anyway?

    I’ve seen situations where CSCdll.dll was going into what appeared to be an infinite loop in winlogon.exe even when offline files was disabled. This was flooring a single core of the processor even after logins finished. On multi-core systems it was surprisingly easy to miss, but on single-core you’d get the responsiveness you’d expect from a processor at 100% utilization.

  54. DanielSuh says:

    Does anybody have an answer for the slow shut down and slow logging off that Chris asked a few messages above?

    Process Monitor is killed before my computer starts to hang. It usually starts to hang at "windows is shutting down" and "closing network connections".

    Any suggestions??

  55. Mr. Slow Logon says:

    Wondering if anyone can provide some insight and recommendations for troubleshooting slow logon experienced on first logon of the day with XP SP2 and XP SP3 laptops.

    If the laptops goes offsite and connects via Juniper VPN to the domain, then upon first logon of the day it takes 3-4-5 minutes.  If the laptop does not go offsite and stays connected to the domain the first logon of the day is around 2 mintes.  I have attributed 30 seconds of that 2 minutes to the fact we have Home folders for each user and when disabled the logon time goes to 1 1/2 minutes.  I can live with that portion of the delay.  

    Wondering if anyone else has experienced this similar issue.  Trying to use Procmon, Netmon and debug logs but not tracking down exactly what is happening.  Getting frustrated to say the least, this has been going on for a very long time and I haven’t been able to pinpoint the root cause.  Have been able to identify machine specific items that contribute to 5-6-7 minute delayed logon instances but haven’t located the silver bullet affecting all laptop users throughout the domain when they roam offsite and connect through VPN…and I truly believe there is one hiding out their somewhere.

    Any recommendations or resolutions with similar issue would be extremely appreciated.

    Thank you,

    "Mr. Slow Logon" (literally)

  56. Juniper's Fault? says:

    Mr. Slow Logon,  have you found any conclusive proof that Juniper is the culprit?  I’m at the same point as you at the moment and it’s frustrating.  I’ve zero’d in on Juniper as the cause of the symptoms also.  

    Has anyone shared any further information with you offline that you’d be willing to share?  Specifically, how to resolve the issue while still using Juniper as a VPN client?  

    I REALLY appreciate ANY information you may have…  


  57. Mr. Slow Logon says:

    @Juniper’s fault?,

    Good morning.

    We have not found any conclusive proof that Juniper is the culprit but I am willing to consider and focus on troubleshooting anything at this point.  Just to be clear, are you saying you are experiencing the same exact issue:

    1. Users going off the domain

    2. Users then using Juniper to connect remotely

    3. User disconnects from Juniper

    4. User coming back to a physical domain connection

    5. User experiencing extremely slow first logon to the domain

    6. Subsequent logons during the same day show a significant improvement

    Unfortunately, no one has shared any additional information regarding the specific issue I have posted(ie. described above), you are the first to respond with the same issue.

    Can you provide some additional detail as to the exact symptoms you are experiencing and maybe together we can bring this to a resolve or at a minimum zero in on the culprit and determine if it is related to Juniper!

    Thank you for the reply…this is now making me think of a whole other subset of potential causes.

  58. Fearless says:

    Mark, You are a superhero of the IT field.  Thank you for answering the Bat-Signals.

    For those having trouble running procexp.exe at login…this worked for me

    Windows 2003 AD Env./WinXP Clients

    Requires two networked comptuers:

    1.  Install Process Explorer on remote computer (computer experiencing slow login). Install Path=c:sysint

    2.  Remote computer status, idle @ CTRL+ALT+DEL screen.

    3.  From another computer on the network…Run:

    psexec \remotecomputer -sid c:sysintprocexp.exe

    4.  Log in to remote computer with any user.

    Hope this helps!  Cheers, Fearless

  59. Juniper's Fault? says:

    @ Mr. Slow Logon,

    In our case, the issue begins to occur as soon as the Juniper client is installed.  After installing the client, after a few reboots the slowness begins.  

    It seems to be the first logon, so long as the machine isn’t rebooted.  From what I can tell, multiple important services don’t start as quickly as they used to, such as WMI and certain network related services.  (I don’t have a complete list- the WMI service alone was enough to cause alarm in our environment.)  

    Strangely enough, if I uninstall Juniper, make sure the services are all removed, and clean out the registry- the issue doesn’t go away.  It doesn’t START until I install Juniper, but it takes a re-image to make it go away once it starts.

  60. Bilchenko says:

    My experience:

    XP SP3.

    psexec –sid SysIntApp.exe

    procexp.exe work after logoff

    Procmon.exe (1.26, 2.8) closed on logoff

    Filemon.exe (6.2) work after logoff

    To Mark: Tank you for your job

  61. LuCas says:

    Disable WEBCLIENT Service first.

    Read the following article:

    Hope it helps,


  62. agressiv says:

    Ever thing that Process Explorer or Process Monitor could be run remotely via a permanent daemon?  I want to say at least a few of the old Winternals utilities had a commercial version which could run this way.

    This way we wouldnt have to mess around with the interactive desktop etc.



  63. Steven says:

    I am performing boot time logging with the latest version of Procmon.  The tracing seems to work fine and when I launch Procmon post reboot I am asked to save the PML log (all good).  But, when I go to open the files (there are 6), I get the follow error: "…was not closed cleanly during capture and is corrupt."

    Any thoughts?

  64. San Diego Mobile nOtary says:

    Wow!  Great post Mark.  I just ran across your blog and was captivated by the detail you apply to seemningly all you posts.  Slow login time isn’t an issue for me currently, but has been in the past many times.  To be honest, I need to read this article a couple more times to grasp what you said better.

    I will be a regular reader of your blog now.  More people should apply the level of detailed analysis you provide.  Thanks for taking the time to do this.

    Have a nice weekend.

  65. Neil says:

    I once had to troubleshoot a slow logon. It only seemed to affect one server. Turned out to be my fault for updating bginfo.exe (which gets run by group policy) and the new version just sat there invisibly waiting for its EULA to be accepted… I have of course added the accepteula parameter to the group policy command line, but in the mean time I was wondering what the point of running the application invisibly was.

  66. tam says:

    In my case, if I try to login right after a reboot, it takes 6 minutes.  If I wait 7 minutes after a reboot, login only takes a minute and a half.  So it seems like a lot of stuff loads in the background after a reboot.

  67. manu says:

    It was an amazing blog Mark. Keep up the good work