The Case of the Delayed Windows Vista File Open Dialogs

re: The Case of the Delayed Windows Vista File Open Dialogs

Sean McLeod — Mon, 27 Nov 2006 22:14:36 GMT

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?

re: The Case of the Delayed Windows Vista File Open Dialogs

CypherBit — Mon, 27 Nov 2006 22:45:31 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Ed Plunkett — Mon, 27 Nov 2006 23:01:23 GMT

Systemic problem

Foolhardy — Mon, 27 Nov 2006 23:56:11 GMT

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.

Tim Anderson’s ITWriting - Tech writing blog » Mysterious Windows Vista hang explained

Tue, 28 Nov 2006 14:44:19 GMT

PingBack from http://www.itwriting.com/blog/?p=62

re: The Case of the Delayed Windows Vista File Open Dialogs

denis bider — Tue, 28 Nov 2006 14:44:47 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Tim Anderson — Tue, 28 Nov 2006 14:45:52 GMT

> Does this delay also occur if your network

> adapter's media connection is 'disconnected'

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

Tim

re: The Case of the Delayed Windows Vista File Open Dialogs

Dave — Tue, 28 Nov 2006 16:56:27 GMT

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

re: The Case of the Delayed Windows Vista File Open Dialogs

CypherBit — Tue, 28 Nov 2006 18:03:09 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Neil Prestemon — Tue, 28 Nov 2006 21:11:39 GMT

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

re: The Case of the Delayed Windows Vista File Open Dialogs

Anon — Tue, 28 Nov 2006 21:29:41 GMT

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.

adapter's media connection ...

ddebug — Tue, 28 Nov 2006 23:39:56 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Brian Keller — Wed, 29 Nov 2006 21:52:00 GMT

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?

re: The Case of the Delayed Windows Vista File Open Dialogs

Hayden — Thu, 30 Nov 2006 05:08:31 GMT

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?

re: The Case of the Delayed Windows Vista File Open Dialogs

rivet — Thu, 30 Nov 2006 06:40:40 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Nicholas — Thu, 30 Nov 2006 18:12:17 GMT

Mark,

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

re: The Case of the Delayed Windows Vista File Open Dialogs

James — Fri, 01 Dec 2006 03:37:32 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Gareth — Fri, 01 Dec 2006 04:43:30 GMT

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

shahine.com/omar/ - Um, great... I love bugs

shahine.com/omar/ - Um, great... I love bugs — Fri, 01 Dec 2006 10:22:30 GMT

PingBack from http://www.shahine.com/omar/UmGreatILoveBugs.aspx

Michael Tsai - Blog - Delayed Windows Vista File Open Dialogs

Michael Tsai - Blog - Delayed Windows Vista File Open Dialogs — Fri, 01 Dec 2006 19:16:24 GMT

PingBack from http://mjtsai.com/blog/2006/12/01/delayed-windows-vista-file-open-dialogs/

Un lugar en el mundo… » Blog Archive » Retazos de la semana (y III)

Un lugar en el mundo… » Blog Archive » Retazos de la semana (y III) — Sat, 02 Dec 2006 16:34:25 GMT

PingBack from http://blog.unlugarenelmundo.es/2006/12/02/retazos-de-la-semana-y-iii/

re: The Case of the Delayed Windows Vista File Open Dialogs

Tweety — Sun, 03 Dec 2006 22:54:54 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Steve — Thu, 07 Dec 2006 01:54:50 GMT

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

Same sort delays in DevStudio with WinXP

Will White — Fri, 08 Dec 2006 21:08:55 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Erwin Ried — Mon, 11 Dec 2006 08:14:59 GMT

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

re: The Case of the Delayed Windows Vista File Open Dialogs

DL — Wed, 13 Dec 2006 01:29:07 GMT

Amazing! I just love your posts...

re: The Case of the Delayed Windows Vista File Open Dialogs

Jo — Sun, 17 Dec 2006 14:09:50 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

micaman — Sun, 31 Dec 2006 12:05:35 GMT

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.

Use NewSID on cloned virtualised machines

The Electric Wand — Wed, 24 Jan 2007 22:21:25 GMT

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

re: The Case of the Delayed Windows Vista File Open Dialogs

micaman — Sat, 27 Jan 2007 10:26:41 GMT

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

Keep up the GREAT work!

re: The Case of the Delayed Windows Vista File Open Dialogs

Christian Kaiser — Thu, 15 Feb 2007 12:20:11 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

King Kevin — Tue, 20 Feb 2007 14:18:15 GMT

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?

re: The Case of the Delayed Windows Vista File Open Dialogs

Andrew — Thu, 01 Mar 2007 19:57:10 GMT

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,

~Andrew

re: The Case of the Delayed Windows Vista File Open Dialogs

Jonathan — Sat, 17 Mar 2007 00:32:13 GMT

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.

Back on XP « Deep Fried Tech

Back on XP « Deep Fried Tech — Tue, 27 Mar 2007 02:46:42 GMT

PingBack from http://www.lockergnome.com/nexus/deepfriedtech/2007/03/26/back-on-xp/

Vista File Open Dialogs--GUI hang even on DC's LAN

A7 — Sat, 31 Mar 2007 07:28:17 GMT

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.

fix by removing Vista systems from domains

A7 — Sat, 31 Mar 2007 19:35:32 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

DjNikos — Sat, 07 Apr 2007 04:21:40 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

mrockman — Mon, 09 Apr 2007 01:20:55 GMT

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.

Windows Vista langsom ved "File Open" dialog

TM — Wed, 11 Apr 2007 18:44:03 GMT

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

re: The Case of the Delayed Windows Vista File Open Dialogs

Woman — Thu, 19 Apr 2007 13:02:24 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Cheaha — Mon, 23 Apr 2007 21:24:44 GMT

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

re: The Case of the Delayed Windows Vista File Open Dialogs

Patrick Weichmann — Sat, 28 Apr 2007 12:45:28 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Craig Matthews — Wed, 02 May 2007 16:37:00 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

AndyB — Tue, 05 Jun 2007 12:28:28 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Kevin Reeuwijk — Tue, 10 Jul 2007 17:12:40 GMT

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 :-)

re: The Case of the Delayed Windows Vista File Open Dialogs

shrike64 — Thu, 12 Jul 2007 16:51:37 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Julian Eli Capata — Sat, 14 Jul 2007 22:44:02 GMT

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!

re: The Case of the Delayed Windows Vista File Open Dialogs

Daniel — Thu, 19 Jul 2007 19:02:35 GMT

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

re: The Case of the Delayed Windows Vista File Open Dialogs - one year later

Gudrun Haus — Tue, 02 Oct 2007 17:30:19 GMT

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?

re: The Case of the Delayed Windows Vista File Open Dialogs

Carson — Thu, 18 Oct 2007 17:20:44 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Dody Suria Wijaya — Sat, 27 Oct 2007 07:00:34 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Dody Suria Wijaya — Sat, 27 Oct 2007 07:05:45 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Mohmammad Husseini — Sun, 04 Nov 2007 21:26:13 GMT

Finaly a great solution by Dody Suria Wijaya

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

re: The Case of the Delayed Windows Vista File Open Dialogs

Khuzema — Tue, 06 Nov 2007 16:48:47 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Marty Jay — Wed, 07 Nov 2007 02:45:38 GMT

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

re: The Case of the Delayed Windows Vista File Open Dialogs

scolombo — Sat, 17 Nov 2007 21:10:52 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Frisky — Mon, 19 Nov 2007 16:57:09 GMT

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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Patrick Anderson — Sun, 25 Nov 2007 11:20:50 GMT

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 www.cnn.com instead of http://www.cnn.com, unless of course I connect to the original domain via VPN.....

re: The Case of the Delayed Windows Vista File Open Dialogs

Jeremy — Sat, 15 Mar 2008 06:51:54 GMT

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://" 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!

re: The Case of the Delayed Windows Vista File Open Dialogs

Luciano Schaper — Fri, 06 Jun 2008 18:03:57 GMT

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

re: The Case of the Delayed Windows Vista File Open Dialogs

Doug Lennox — Mon, 25 Aug 2008 02:39:22 GMT

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 vista-pc.lennox.com.au 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.

re: The Case of the Delayed Windows Vista File Open Dialogs

Alpharat — Mon, 27 Oct 2008 00:52:38 GMT

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

re: The Case of the Delayed Windows Vista File Open Dialogs

Glenn — Mon, 24 Nov 2008 03:59:10 GMT

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!

re: The Case of the Delayed Windows Vista File Open Dialogs

Glenn — Mon, 24 Nov 2008 04:19:23 GMT

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

This also applies to Win XP (at least for me)

Uwe Jugel — Wed, 03 Dec 2008 15:42:12 GMT

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?

re: The Case of the Delayed Windows Vista File Open Dialogs

Richard — Fri, 27 Feb 2009 00:57:15 GMT

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.

Thanks

Richard