Last fall, I spoke at the Microsoft Tech Ed: IT Forum conference in Barcelona, Spain. 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, I noticed that the File Open dialog box, which is common to all Windows applications, would often take as long as 15 seconds to appear. The behavior seemed similar to the behavior I wrote about in "The Case of the Process Startup Delays" (http://blogs.technet.com/markrussinovich/archive/2006/08/31/453100.aspx). In that case, Windows Defender's remote procedure call (RPC) communications tried to contact a domain controller (DC), which resulted in hangs when the system was disconnected from its domain.
To investigate the problem, I launched Notepad from within Windbg (part of the free Debugging Tools for Windows available at http://www.microsoft.com/whdc/devtools/debugging/default.mspx), 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.
A look at the function names on the stack immediately told me what was happening: When you access the File Open dialog box the first time within an application, it navigates to your Documents folder. On Vista, my folder is C:\Users\Markruss\Documents, but the shell wants to make the path in the dialog box's new bread crumb bar (which shows the trail of accessed folders—i.e., breadcrumbs) pretty by displaying it as "Mark Russinovich\Documents." So it calls GetUserNameEx to look up my account's display name as it's stored in my User object in Active Directory (AD).
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 defines 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 Open File dialog box's breadcrumb bar referenced "markruss." However, when I reconnected to the corporate network, the breadcrumb bar referenced "Mark Russinovich."
You can read the detailed description of the steps I took to solve the Open
File dialog box hangs at https://blogs.technet.com/markrussinovich/archive/2006/11.aspx,
but to summarize, I discovered that Vista's File Open dialog box tries to look
up a user's display name for the breadcrumb bar when showing the Documents folder,
and in the process, tries to locate a DC by sending a LAN Manager datagram via
the Bowser.sys device driver. There's no workaround and anyone that has a domain-joined
system that's not connected to the domain for more than 30 minutes will experience
the same delays—at least until Vista Service Pack 1 (SP1).
—Mark Russinovich
This is a summary of a popular posting to Mark Russinovich's technical blog (https://blogs.technet.com/markrussinovich/about.aspx), which covers topics such as Windows troubleshooting, technologies, and security. You can read the entire post at https://blogs.technet.com/markrussinovich/ archive/2006/11.aspx