The Case of the Delayed Windows Vista File Open Dialogs

I was in Barcelona a couple of weeks ago speaking at Microsoft’s TechEd/ITForum conference, where I delivered several sessions (two, Advanced Malware Cleaning and Windows Vista Kernel Changes earned the top #1 and #2 rated breakout sessions for the week - you can see an interview of me at the conference here). The conference was a huge success and Windows Vista, which I had taken on the road for the first time, performed great. However, as I was running through some demos before one of my sessions, I noticed that the file open dialog, which is common to all Windows applications, would often take between 5 and 15 seconds to appear.

I didn’t have time to investigate before my talk, so the delays caused me consternation when they showed up during my Windows Vista Kernel Changes session immediately afterward. The behavior felt uncannily like the one I wrote up a few blog posts ago in The Case of the Process Startup Delays. In that case, Windows Defender’s Remote Procedure Call (RPC) communications during process startup tried to contact a domain controller, which resulted in hangs when the system was disconnected from its domain. I mumbled excuses on behalf of Windows Vista and tried to distract the audience by explaining the subsequent demonstrations.

It wasn’t until the plane ride home that I got a chance to look into it. I followed steps similar to the ones I had when I explored the Windows Defender hangs. I launched Notepad from within Debugging Tools for Windows’ Windbg tool, typed Ctrl+O to open the File Open dialog, and when I got the hang broke in and looked at the stack of Notepad’s main thread:

If you haven’t seen a stack before, it’s a history from most recent to least of nested functions called by a thread. You read it from bottom to top, so the stack shows that Notepad had loaded Browseui.Dll and called its CAddressBand::SetNavigationState function. That function called CBreadcrumbBar::SetNavigationState, which called CBreadcrumbBar::SetIDList, and so on.

A look at the function names on the stack immediately told me what was happening: when you access the Open dialog the first time within an application it navigates to your documents folder. On Windows Vista my folder is C:\Users\Markruss\Documents, but the shell wants to make the path in the dialog’s new “bread crumb” bar pretty by displaying it as “Mark Russinovich\Documents”, and so it calls GetUserNameEx to lookup my account’s display named as it’s stored in my User object in Active Directory. I confirmed my theory by verifying that the first parameter SHGetUserDisplayName passes to GetUserNameEx, which is interpreted as the EXTENDED_NAME_FORMAT enumeration, is 3: NameDisplay.

I set a breakpoint on the call’s return and hit it after the delay completed. GetUserNameEx returned the ERROR_NO_SUCH_DOMAIN error code, and stepping through SHGetUserDisplayName revealed that it falls back to calling GetUserName. Instead of looking up the user’s display name, that function just obtains the Security Identifier (SID) of the user from the process token (the kernel data structure that defined the owner of a process) and calls LookupAccountName to translate the SID to its account name, which in my case is simply “markruss”. Thus, the dialog that appeared looked like this:

As opposed to this, which is what I saw when I got back to the office and connected to the corporate network:

I had solved the case, but was curious to know where exactly the delay was taking place and so continued by researching what was happening on the other end of the Secure32!CallSPM call that’s on top of the stack listing. I knew that the Local Security Authority (LSASS) process is responsible for authentication, including interactions with domain controllers and account name translations, so I attached Windbg to the Lsass.exe process (make sure that you detach the debugger from LSASS before exiting with the “qd” command, otherwise LSASS will terminate and the system will begin a 30-second shutdown). I figured that Secur32.Dll acts like both a client and server and confirmed that it was loaded into LSASS, but I needed to determined the server-side function that corresponds to Secur32!SecpGetUserName. I did so by brute force: I dumped the functions implemented by Secur32.Dll and looked for ones with “name” in them:

I set breakpoints on several of them and when I reproduced the delay I hit the one on SecpGetUserName and stepped through it to eventually get to this stack:

The DsGetDcName function is documented as returning the name of a domain controller in the specified domain. SecpTranslateName obviously need to find a domain controller to which to send the account display name query. I traced further, and discovered that LSASS caches the result of the lookup for 45 seconds, which explained why I didn’t see the delay if I ran a different application and accessed the File Open dialog immediately after getting a delay. Then I hit a temporary dead-end when Netapi32!DsrGetDcNameEx2 executed a RPC request.

Again, figuring that Netapi32 acts like a client and a server, I dumped its symbols and set breakpoints on functions containing “dc”. I let LSASS continue executing and to my surprise hit the exact same function, Netapi32!DsrGetDcNameEx2. I traced into the call deeper and deeper until the thread finally called into the kernel (Ntdll!KiFastSystemCallRet):

I was close to the end of my investigation. The last question I had was what device driver was Netlogon calling to send a browser datagram? I answered this by looking at the first parameter it passed to NlBrowserDeviceIoControl, which I guessed was a handle to a file object. Then I opened Windbg in Local Kernel Debugging mode (note that on Windows Vista you have to boot in debugging mode to do this), which lets you look at live kernel data structures, and dumped the handle’s information. That showed me the device object that was opened, which told me that the driver is Bowser.sys, the “NT Lan Manager Datagram Receiver Driver”:

I thought my investigation was complete, but when I later tried to reproduce the delays I failed. I retraced my footsteps and found that LsapGetUserNameForLogonSession caches the display name for 30 minutes. Further, an account’s display name is cached with cached credentials so you won’t experience the delays for the first 30 minutes after logging in or disconnecting from the corporate network.  I confirmed that by waiting 30 minutes and reproducing the hangs.

My investigation had come to a close. I had determined that Windows Vista’s File Open dialog tries to look up a user’s display name for the “bread crumb” bar when showing the documents folder and in the process tries to locate a domain controller by sending a Lan Manager datagram via the Bowser.sys device driver. I also knew that there’s no workaround for the delayed dialogs and that anyone that has a domain joined system that’s not connected to their domain will experience the same delays - at least until Windows Vista Service Pack 1.

Comments (67)
  1. Anonymous says:

    I came across a problem recently when a colleague was building a virtual Windows Server environment,

  2. Anonymous says:

    Jeg har haft et "stort" problem med at hver gang jeg åbner "My Computer" eller andre "File Open" dialogbokse.

  3. Anonymous says:

    IMO, this is part of a systemic design error in the shell that has existed since at least Windows 95: the shell is far too synchronous.

    The shell should never be making a blocking network request in the GUI thread. This is only the latest example of the shell being unresponsive because it is blocking on some event that, predictably, can and will take a long time to complete or timeout.

    The problem is so big that the kernel team has had to implement a special syscall to cancel a synchronous IO operation in another thread. This is at best a work-around: the correct solution would’ve been to have the GUI thread not actually block on these events, either directly via asynchronous IO, or with an army of worker threads to do the blocking (with async notification back to the GUI thread).

    The last thing that should be happening is for the GUI thread itself to block on a superficial username lookup, network computer enumeration, domain controller lookup, CD-ROM volume names, or any other kind of lengthy IO. This is, unfortunately, the current design of the shell.

    CUsersFilesFolder::GetDisplayNameOf shouldn’t be calling GetUseNameExW in the GUI thread (unless it somehow knows the answer has been cached and won’t block.) Instead, it should display the most correct answer it can retrieve immediately, and have a worker thread block on GetUserNameExW. When GetUserNameExW returns, it can inform the GUI thread that a better display name has become available and the GUI thread can update accordingly. I could see the GUI thread waiting for a response for a short time  from the worker (say 200ms) to help avoid flicker. This strategy should be applied to all shell display elements that might block for nontrivial amounts of time.

    I never use the network neighborhood because it WILL block for 10+ seconds, leaving the entire window unresponsive.

    I know that Win95 didn’t support async IO and couldn’t afford to create tons of threads, but they still could’ve used two (one for GUI, one for background) Besides, I thought Vista was supposed to fix this kind of thing.

  4. rivet says:

    Its re-assuring to see you posting this kind of work while employed by Microsoft. I imagine I’m not the only one that wondered if you would no longer be able to post things that are embarrassing to your employer.

    Its interesting to see that taking a domain member workstation away from the domain still has problems and delays. I suppose this is a demonstration of the evolution of the operating system. Had it been designed for such it would no doubt have a storage cache for all of the information it might need while offline so that these calls don’t waste time.

    As mentioned above its kind of surprising that there isn’t a fast bypass to these checks when there is no attached network. That would make sense, but I supose that would simply be another hack to get around previously unplanned usage.

    Thanks again Mark. Always a good read.

  5. Neil Prestemon says:

    Would it be possible to simply hit a registry value to increase that cache time from 30 minutes to something longer?

    Or maybe there’s a way to hit a registry value to change this behavior so that populating the breadcrumb bar will skip over the GetUserDisplayName, and substitute the regular UserName (culled from the file-system path) – for example, if Vista is in Workgroup Mode, it’s not going to even try to look up the UserDisplayName in Active Directory.  So maybe there’s a regkey somewhere that will "fool" Vista into thinking it’s in Workgroup mode – for times when the box is not connected to the network.

    Quite often, Windows developers will embed keys like this, as little undocumented hacks to help them test certain scenarios, and for one reason or another (usually at the behest of a Marketing dweeb) that key remains undocumented or unexposed.

    Mark has done a fine job of exposing the behavior of the system, but one does not always have to live with that as the default.  

    (Of course there are trade-offs – I think both of these possible workarounds would likely be security risks.)

  6. Anonymous says:

    I run vista ultimate on a notebook which is not joined to any domain and experiencing the same problem , long delay on "file open/save " box operation.

  7. Does this delay also occur if your network adapter’s media connection is ‘disconnected’ or only if you’re connected to some physical network but without a network path to your domain controller?

  8. CypherMike says:

    Great detective work as always.

    It is however a shame no one bothered to disconnect from their domain and test this before RTM. Millions of users will be quite unhappy having to wait for something to open (for longer then usual) on their brand new notebooks.

  9. Ed Plunkett says:

    See also:

    …not to mention the DevStudio 2005 help viewer which invalidates the entire sidebar every time you click on anything in it. And the CLR.

    They’ve gotten badly off track.

    Things will be dismal for a while until competent competitors appear (let us pray that they do…).

  10. denis bider says:

    Foolhardy: The problem is not just the Windows shell, it is the design of the Win32 API. Loads upon loads of functions that can and will block for long periods of time are available in synchronous versions only, for "ease of use". They’re "easy to use" alright, but the result is a crappy experience for the user.

  11. Tim Anderson says:

    > Does this delay also occur if your network

    > adapter’s media connection is ‘disconnected’

    Doesn’t seem to, I just tried it. No delay.


  12. Dave says:

    CypherBit: "It is however a shame no one bothered to disconnect from their domain and test this before RTM."

    Well, bugs happen, and the fact that it caches the information for half an hour makes it even harder to repro.

    Even if a fix is written today, it will be sitting in on a disk drive somewhere for the next 6 to 12 months until Vista SP1. With guys like Mark on staff, Microsoft can write bugfixes, but their process prevents them from shipping bugfixes in a reasonable time frame. You see, it has to be tested with the Urdu distribution, and we have to ensure no bad interactions with the Zune player, and …

  13. CypherMike says:

    Dave: Of course bugs happen, but this one does seem a bit obvious. Not the fact what’s wrong, but that something is wrong. I’d imagine a lot of testers were disconnected from their DC for quite some time, they might have even traveled and it just surprises me no one noticed this. That’s all.

  14. Anon says:

    Foolhardy: AMEN. This has frustrated me for years.

    It feels like MS are forever extending the same tired 10-plus-year-old design.

    I’m sure much of the code has improved beyond recognition, but still it retains this awful clunkiness.

    A serious revamp is overdue.

  15. ddebug says:

    Sean McLeod hit the nail on it’s head.

    A domain related API should have fail quickly when there is no visible domain connection.  So Mark’s investigation actually gives a strong alibi to the shell, and the culprit is some underlying layer of smartness in the base network that should detect connection to the domain. It can be that layer or feature even does not exist yet, or haven’t made it to RTM.

    Instead, there is a primitive try-and-cache logic.

    The computer obviously was connected in some way (to the public internet or whatever) – so the media connection state by itself isn’t very useful.

  16. Brian Keller says:

    Very interesting post, but on my machine (Vista RTM) I am seeing a delay but it’s < 3 seconds on first invocation and no delay on subsequent invocations. What is your Windows Experience Index? Mine is 3.0 for my laptop. Are running in a VPC by any chance?

  17. hayden says:

    Augh! Synchronous shell again! I never cease to be irritated how this allegedly multi-tasking OS is frozen by, say inserting a CDROM. It’s rubbish. And monumentally lazy on the part of the planners. Wasn’t Vista supposed to be a drains-up rework of XP?

  18. Nicholas says:


    Great article as always. This is really annoying, and something I’d hoped had been fixed in Vista. Ugh.

    Anyway, you might want to do some debugging on  iTunes in Vista.. it’s terrible! Not sure what’s going on there, but looking at the output from Process Monitor, iTunes makes calls and registry hits all over the place that have nothing to do with anything. And when it goes to read/write data, it gets a "FAST IO DISALLOWED" — which I would assume accounts for a lot of the slowness.

    I’m off to write a blog post in my own blog about how much iTunes sucks in general…

  19. james says:

    Large blocked UI periods caused by network timeouts have been systemic throughout Windows’ lifetime. For that reason I’m surprised more wasn’t done to test for this sort of thing.

    One would have hoped that Microsoft had done a lot to fix these. Maybe they have but created a new "worse" one that will lead to a delay every 30 minutes when opening a file if you are connected to a different network with no route to your DC.

  20. gareth.douce says:

    Great read.  

    However, why is the UserName only being cached for 30 minutes?  How often does this information actually change in the real world?  

    Changes are hardly a regular event – most will probably never change.  Would it really matter if it were wrong whilst someone was disconnected?   It primarily gets used for these display purposes anyway…..

  21. Tweety says:

    Omg… I know you work for MS, but how not to tell MS sux? It’s incredible how such small little things make Windows be so hated. Such little pauses and bugs.

    I think fixing this should not be a problem, just disable this name displaying function if I’m not connected to my network. One IF statement. So hard? I don’t think so, but MS do.

  22. Steve says:

    This is a very annoying bug.  

    On a side note, maybe related or not, I’m experiencing a delay when launching IE from the quick start bar.  (Going into the start menu and launching works OK.)  Only happens when I’m of the domain.  Very annoying!!

  23. Will White says:

    I have the same kind of delay with the File Open dialog box in Developer Studio (VB 2005).  Not just when I open the dialog, but everytime I change paths.  It only happens once in a while, but it’s really annoying.

  24. Erwin Ried says:

    Very good investigation, I personally do some minor fixes (and cracks) on Windows (only XP for now) with your incredible tools, specially Regmon and Filemon

  25. DL says:

    Amazing! I just love your posts…

  26. Jo says:

    Can’t they just make it on another thread so that window would work normally and second thread would connect to domain and get names?

    Threads! Windows really needs threads.

    The same goes to connecting to computer on network – if here is delay on connect whole explorer hangs… if it would be on thread it would work great.

  27. micaman says:

    Thanks for explaining the process in such detail. It allowed me to find where I was making a few mistakes performing this task. I am thankful that you take the time to post your work.

  28. micaman says:

    Maybe Microsoft will allow you to build a tool to fix this problem sooner than Vista SP1?

    Keep up the GREAT work!

  29. Christian Kaiser says:

    One thing I noted, apart from the whole problem of delay, and I write it very carefully: there is at least some MS source code that is not reviewed by a second person.

    Look at the misspell error "FileSystem/bowser", which a code review should have found esily. Some Windows APIs and other symbol files reveal the same problem.

  30. King Kevin says:

    Mark – I have a similar problem, but they NEVER let me File>Open. It freezes up the prog, and no domain controller in site.

    Any ideas?

  31. Andrew says:

    I agree that this is annoying…but have any of you worked on OS X, especially anything prior to 10.4?

    Apple has done the same stupid stuff.  I know this is an MS thread and that just because another company does the same dumb things is not at all a justification for another’s behavior.

    However, we should be demanding better quality for these simple user experience issues from all of our prefered OS vendors or open-source developed OS’s.

    These sorts of "shell" issues seem to permeate all of them.

    It’s like the devs are so pressured / focused to just "get it out the door" that these sorts of bugs are sorted at the bottom on a .Zero release…to be "maybe" fixed in the .One (i.e. SP1 or 10.x).

    My 2 cents,


  32. Jonathan says:

    Part of the problem as I see it is that the function to search for a domain controller has an inherent timeout of 30 seconds (or so). This delay is necessary, to avoid problems in the situation where a domain controler IS available but across a WAN link, and NetBIOS browse lists must be replicated. If the domain controller is not listed in the local browse master’s browse list, then the domain controller must be discovered by broadcast; this can take time especially over a slow WAN link. ddebug, this is why your suggestion is not feasible: a short timeout is insufficient to determine the domain is indeed unavailable.

    The security model of Windows favors contacting a domain controller if available, to verify updates to security acocunts, policy, etc. Ultimately, a domain member that is disconnected from the domain is operating in a lower security mode, as security cannot be verified against the security authority, the domain controller.

    By default (at least in XP and earlier), a domain member will only permit 10 sequential logins against cached credentials before a domain controller can be contacted (this can be changed, to a maximum of 50, by policy).

    Really, the solution is to make eye candy low priority, so it cannot "lock up" the system. Display "ugly" information if necessary, then update it when the "pretty" information becomes available, as suggested by Foolhardy. Hopefully this will be a Vista SP1 fix.

  33. A7 says:

    The problem seems to be even worse that you suspect because we have test systems continuously connected to a Windows 2003 R2 domain and on the same gigabit LAN as the DC itself.

    On at least one test system, and for reasons that we are unable to decipher, the file dialog hang and general file operation GUI hang happens all the time. Domain access at the same moment is excellent. We can even have a high-speed file transfer copying data to or from the DC at the same moment that another of the endless GUI hangs occurs because a file dialog or file browsing window has been opened.

    Vista is so rotten in its initial release that we have scuttled all roll-outs for customers until these major bugs are fixed. Many have heard about these terrible defects independently and their opinion of Microsoft is at all-time lows.

    We don’t sell Linux systems, so this leaves us having to continue pushing XP out the door. We couldn’t be more disgusted.

  34. A7 says:

    For Vista systems exhibiting this bug in its various forms, we have found that the only viable solution is to remove them from their respective domains and limp along in workgroup mode.

    An earlier post ‘forgave’ the GUI dev teams for using calls to synchronous functions that might cause blocking…. but we don’t because completely unnecessary blocking problems still exist in far too many products.

    A case in point is the MS SQL client for Win Mobile which locks up as users roam their wireless network because it can’t live with any packet loss…  or Office Outlook that still after all these years is chock full of UI stalls due to background processing.

    Microsoft needs a top-to-bottom search-and-destroy program for all the childish  blocking-prone design flaws that still exist in so many of its products. The problem is at least as destructive to information worker efficiency as all of the malware problems put together.

    Blocking problems equal instability.

    For most users, they perceive the blocking as a severe system failure or malware infestation.

    For the real-time environments that we implement, systemic blocking problems are a deal-breaker.

  35. DjNikos says:

    How come this bug isn’t reported in any Vista kb (knowledge base) articles? If it is can someone please point it out to me?

    As a network administrator I’ve had to set a policy of banning Vista in any form on our network because of this, and pointing my users to this issue is enough to stop them requesting vista at all.

    C’mon MS get a hotfix out, this is ridiculous.

    I’ve had to live with Vista in our network for over 2 months and the only way I can seriously use Vista away from the network on a laptop is to be constantly in VPN. Totally ridiculous.

  36. mrockman says:

    Delayed application opening is one of many odd behaviors exhibited by Windows.  Windows is an enormous machine with many inter-related moving parts, that interact is ways that are emphatically not obvious to the casual observer let alone the highly trained expert.  The drive to innovate has lead to increasing complexity which is the mother of unintended consequences and unforeseen circumstances.  I’ve just installed Windows XP SP2 into a reformatted partition for reasons too silly to convey here.  When I click Computer, Windows Explorer opens and the flashlight icon animates for up to 2 minutes before displaying anything useful.  I’ve tried removing and reinstalling the computer in its domain to no effect.  One could descend into a pit of melancholy over this sort of thing.  

  37. Woman says:

    And they wonder why Linux is getting more audience by the day.

    For one it provides control to avoid disasters that plague the entire OS, explorer/shell, IE, all the way up to new server software.

    Even if you run in Workgroup mode you will see issues similar to this.

    It has been a decade of this mess.

    The OS still has irresponsive behaviour (even W2003 R2 SP2 on most recent, blast of the hardware).

    Block, sync, block, RPC, block, shell block, block, block DNS, block block AD, block, block MQ, block, block on large file ops, block, block, thrash pages, block.

    Out of this world.

  38. Cheaha says:

    Please someone report this issue to Microsoft so that a fix can be made.  It is simple too severe a bug to let it go.  Domain installations of Vista have come to a virtual standstill b/c of this issue.  I too am seeing the delay on systems connected to the domain 100% of the time (after exactly 30 minutes).  

  39. Patrick Weichmann says:

    I am now working since November with Vista Enterprise Edition and it is really frustrating.

    I open about 200 times in a couple of hours an explorer window and almost always I have very long delays before I can work again.

    I am usually working many hours a day not connected to the domain. But I cannot work this way, so I installed vmware workstation and built a nice windows xp machine and run that thing in full screen mode.

    Boy is that fast compared to Vista. I can only hope that they get to their wits and fix this immediately. Make vista fast, very fast. It should be anyways.

    Also the networking configuration is very bad. I have to switch networks many times 20 – 40 times a day and the wireless network card does not always work the way it should and I have to restart many times.

    Usually I use netsh but even with netsh it does not work.

  40. The fact that this type of systemic problem still exists is even more upsetting in light of the fact that Microsoft is spending their time on things like voice recognition, as if we’re supposed to believe we live in the 23rd Century, when at the same time we can’t get file open dialog boxes to open or even copy files to a network share within a reasonable time frame.

    And they think it’s time for me to talk to my computer?

    The basics need to be fixed, sorry.

  41. AndyB says:

    I suppose bugs do happen, and they could be much reduced if the development teams at MS had to use the system the way the rest of us do. If 1 employee had a laptop that was disconnected occasionally instead of them all having super-fast multi-core CPUs, fully-loaded with ram, and fast well-designed networks then we’d have a lot fewer of these bugs.

    That said, what could be done – the simple answer is async lookups for all network operations for the GUI, and much less of them. I pray that this would take top priority at MS for the shell team.

    What *will* be done? I hope its not a quick bodge that only papers over this bug while we wait for the next one like it to appear.

  42. Kevin Reeuwijk says:

    I can confirm that this problem has been fixed in Vista SP1. It’s also been fixed in Longhorn Server Beta 3. I ran LH Beta3 for a while, just because it didn’t have those extremely annoying delays. Now with Vista SP1, life is great again 🙂

  43. shrike64 says:

    Excellent detective work and very informative.  I’ve just set up my new Vista laptop, and I have it joined to my work domain.  I’m seeing this delay both in file open/save dialogs, but also in the starting of some applications (I assume they are doing something with the file dialog on startup?)  It’s very frustrating to hear that I’ll have to live with this issue until at least November.  I guess I should have known better than to get my computer with Vista, but I’m eager to start working with it so that I can support it.  Such is life, I guess…  I guess I can try to see what I need to do to get my hands on the SP1 beta.

  44. Julian Eli Capata says:

    I’m not a computer tech, still using dBase III, linked to Access, so my clerks can get my data base(s) up & running, but had my old computer with XP on it fixed so that I can get my work out.  No new computer  purchased until either Vista is fixed or we decide to go to Linux systems — it has to be better!

  45. Daniel says:

    Same with me. It happens to almost EVERY application I try. It takes up 50% of my CPU each time.

  46. Gudrun Haus says:

    Almost a year has passed, and we still struggle with this problem. When are Microsoft going to fix this? And why is SP1 taking so long?

  47. Carson says:

    Last week (October 2007) I set up a brand new Asus (Turion-60 AMD 64 dual-core with 2 gigs of RAM) in Vista. I’ve used computers since 1987, and I’m a skilled end-user with XP. I was horrified by Vista’s slow speed, which reduced this beautiful new computer to being little better than my own ancient Celeron 1.7 with its 128 kb L2 cache. Yes, really; the new machine was a lot smoother, but little faster, crippled by move and copy (and sometimes by rename and delete).

    I had all the updates and patches to date, and every tweak I could find on the internet.

    I regularly move files over a gig. I don’t open a second window; I use "move to" and "copy to" all the time. I don’t even think about it — I don’t have to.

    Well, my experience was so horrifying that I put Vista onto my own machine to test it further. I allowed for my slow L2. The faster machine had rated 4.7, and my slow one rated just 2.5, but the results were pretty close. On mine, I could take more chances experimenting.

    Then I reformatted and returned to XP. I needed to. I needed basic competency with the most basic of file operations.

    Today, for example, I shall need to move a 4.2 gig file around a bit. In fact, it’s a file I’m getting entirely as a result of my rather horrifying experience with Vista. Thank goodness I have XP to handle it.

    The file is Ubuntu 7.10.

  48. Dody Suria Wijaya says:

    You can fix this temporarily without SP1 by disabling NBT (NetBIOS of TCP/IP):

    (1) Open you network card properties.

    (2) Select Internet Protocol Version 4 (TCP/IPv4), click Properties.

    (3) Click Advanced, select WINS tab, select Disable NetBIOS over TCP/IP.

  49. Dody Suria Wijaya says:

    You can fix this temporarily without SP1 by disabling NBT (NetBIOS of TCP/IP):

    (1) Open you network card properties.

    (2) Select Internet Protocol Version 4 (TCP/IPv4), click Properties.

    (3) Click Advanced, select WINS tab, select Disable NetBIOS over TCP/IP.

    This will force vista looking for domain control through DNS query, which should respond quickly than NetBIOS.

  50. Mohmammad Husseini says:

    Finaly a great solution by Dody Suria Wijaya

    Thank so much, all my Networked Vista altima stations are running great now

  51. Khuzema says:

    Even on network with domain controller on my Vista system its taking too much time. Before looking on internet my first understanding was my machine got infected either with viruses or spyware. Had to waste lots of time. And then I came across this post.

    Microsoft marketing for Vista went from very aggressive to level of unethical, to push it on people.

  52. Marty Jay says:

    Honestly, could Microsoft not make a patch for this? I am quite happy using XP and Linux (Debian), but a friend of mine bought a new computer with Vista and it is just unworkable. Since he can’t go back and use XP, he might be forced to use some Linux version. At least there are always free and easy solutions for problems…  nowadays free is definitely better for some purposes…

  53. Frisky says:

    This is great information Mark. However, I have a domain on an old Windows 2000 Server in my home. The Active Directory has crashed on it, and I am going to have to rebuild the domain. But, the real problem is that while this is a brand new dual core laptop that runs everything super fast, if I so much as use an open file dialog I get a delay of no less than 5 Minutes and usally greater than 10 Minutes. Yes, I have actually timed at, and until it became so common, was keeping a log with the times. I don’t recall this problem before my domain crashed. I would love to just switch over to a standard user account, but, then my profile is abandoned, and I have to create all my new profile information from scratch.

  54. Patrick Anderson says:

    Unfortunatelly the solution by Dody Suria Wijaya is not working for me. Still delays up to 30 seconds each time I want to open a folder or save a file, or do a instead of, unless of course I connect to the original domain via VPN…..

  55. jeremy says:

    Thought I would mention that disabling NBT makes my Vista machine scream.  Works around the File Open/Save delays as well as fixes the requirement to type "http://&quot; before addresses in IE.

    One of these days I’ll get around to fixing whatever problem I’m having with my DC, but since this is just my home network, and it lets me on the internet, get email, and play games, it hasn’t been a big priority.

    Thanks Dody!

    Thanks Mark for the EXCELLENT write-up!

  56. Luciano Schaper says:

    I had this problem recently, and reading some forums, I remember I have a dns problem and settled the domain to be settled automatically, so if you are using a domain, try to set it manually.

    hope it helps…

  57. Doug Lennox says:

    This problem persists through to SP1 and all fixes to dates. None of the suggested fixes (and I’ve tried them all) make any difference apart from the option of changing to a Workgroup.

    Strangely many Vista PC’s work OK on domains that we support, but the odd one such as on our own domain has been been completely recalcitrant.

    I suspect that that is because our domain has many PC’s coming and going all the time, and there will always be a few computer names non-responding.

  58. Alpharat says:

    Yes, this is a terrible thing. I am abandoning Vista because this latency issue is so bad. I gave Vista a chance, but if this problem is so deep in the OS, and SP-1 did NOT fix it, then goodbye Vista..this might even drive me away fro Microsoft entirely, either to MacOS or Ubuntu..uuuggghhh..

  59. Glenn says:

    I’m getting same problem and it is so annoying I have installed an ripped off copy of XP. If MS try to sue I will just state I am running it until they fix the faulty product they are selling that is not fit for purpose.

    Patch please!

  60. Glenn says:

    I don’t login to a domain. I use my laptop mainly at home but at work connect to a printer, and two files shares using connect as…

    However I still get this problem and need to reboot every 30mins to get any work done. Hence move back to XP

  61. Uwe Jugel says:

    I have a similar problem under my corporate  Windows XP (SP2) with several file-open/save dialogs.

    broken file-open in:

    – Notepad, Notepad++, Freemind, Firefox, IE6

    not broken in:

    – Office 2007 (Word, Outlook, …)

    Could this be related?

  62. Richard says:

    Finally a great solution by Richard

    Thank so much, the mysterious slow accounts section with all their Networked Vista accounting software stations are running properly in fact Great.



Comments are closed.

Skip to main content