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
End of Article
Register
