When to debug… and when not to.
There are some people who think "If only we could debug this, then we can finally determine what’s wrong"
But is that always the best option?
The debugger is just another tool, like a network trace or something traditional like regmon or filemon. It’s not a magic tool that illuminates the solution automagically, nor is it always the best tool for the job (even in the hands of someone who is an excellent debugger).
A few recent examples which will also show you the kind of stuff we work on around here.
Problem #1
Customer had the error below when trying to launch Programs \ Administrative Tools \ "Domain Security Policy" or "Domain Controller Security Policy”
“Failed to open the Group Policy Object. You may not have appropriate rights.”
When he launched the Domain Policy editor from GPMC or in box methods – it would not bring up the Domain Policy, instead the local policy would come up.
After troubleshooting it for a while, engineer X called me and asked if I could debug it.
Now – if you look at the shortcut properties in the admin tools you will notice that we pass in a number of params to the .MSC file:
C:\WINDOWS\system32\dompol.msc /gpobject:"LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=crisco,DC=com"
Within a bit, I noticed that the parameters were not being passed properly:
0:000> kb2
ChildEBP RetAddr Args to Child
0006eeb0 686b8ca9 00914540 0091463c 00000000 kernel32!GetCommandLineW
0006f108 7275d973 00ed1c0c 000b3310 0091bd30 GPEdit!FooFunc+0x58
0:000> g 686b8ca9
eax=0002079c ebx=00000000 ecx=686915e8 edx=00000000 esi=000b3310 edi=00914540
eip=686b8ca9 esp=0006eeb8 ebp=0006ef44 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
GPEdit!FooFunc+0x58:
686b8ca9 ff758c push dword ptr [ebp-0x74] ss:0023:0006eed0=00ed1c28
0:000> du 0002079c
0002079c ""C:\WINDOWS\system32\mmc.exe" ""
000207dc "C:\WINDOWS\system32\dcpol.msc""
I tried this from the cmd line:
"C:\WINDOWS\system32\mmc.exe" "C:\WINDOWS\system32\dcpol.msc" /gpobject:"LDAP://CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=crisco,DC=local"
NOTE: notice that I specify the MMC.EXE process and the .MSC file
And it worked OK. So where to go from here? <Answers at the end of post>
Problem #2
When you configure a user to have a roaming profile, the roaming profile upload fails after slow link dialog is displayed and user selects 'yes' to upload the profile.
Userenv logging shows that we fail here:
USERENV(1fc.200) 17:53:31:849 CheckForSlowLink: Calling DialogBoxParam
USERENV(1fc.200) 17:53:33:532 LogoffSlowLinkDlgProc:: Killing DialogBox because upload button was clicked
USERENV(1fc.200) 17:53:33:542 CopyProfileDirectoryEx: Entering, lpSourceDir = <C:\Documents and Settings\TestUser>, lpDestinationDir = <E:\TestUser\Std>, dwFlags = 0x6c20
USERENV(1fc.200) 17:53:33:542 CopyProfileDirectoryEx: lpExclusionList = <Local Settings;Temporary Internet Files;History;Temp;>
USERENV(1fc.200) 17:53:33:542 ConvertExclusionList: Adding C:\Documents and Settings\TestUser\Local Settings to ExclusionList
USERENV(1fc.200) 17:53:33:552 ConvertExclusionList: Adding C:\Documents and Settings\TestUser\Temporary Internet Files to ExclusionList
USERENV(1fc.200) 17:53:33:552 ConvertExclusionList: Adding C:\Documents and Settings\TestUser\History to ExclusionList
USERENV(1fc.200) 17:53:33:562 ConvertExclusionList: Adding C:\Documents and Settings\TestUser\Temp to ExclusionList
USERENV(1fc.200) 17:53:33:562 CreateNestedDirectory: CreateDirectory failed with 3.
USERENV(1fc.200) 17:53:33:572 CopyProfileDirectoryEx: Failed to create the destination directory. Error = 3
USERENV(1fc.200) 17:53:33:572 CopyProfileDirectoryEx: Leaving with a return value of 0
USERENV(1fc.200) 17:53:33:582 UnloadUserProfileP: CopyProfileDirectory returned FALSE for primary profile. Error = 3
USERENV(1fc.200) 17:53:33:582 ReportError: Impersonating user.
USERENV(1fc.200) 17:53:33:582 ReportError: Logging Error <Windows cannot update your roaming profile. Possible causes of this error include network problems or
insufficient security rights. If this problem persists, contact your network administrator.
C:\>net helpmsg 3
The system cannot find the path specified.
The file server was available and there were no name resolution issues ( profile loads fine when initial load occurs from file server )
Network traces did not show any foul play..
Where to go with this one?
Problem #3
After a particular security fix is installed, drag and drop to a DFS link fails. You left click on the file – drag it to the window which displays the DFS link and when it hovers over the window you get the little circle with a line thru it indicating that the target is not valid. Same file dragged over a standard file share works fine.
Client in this case is Windows 2000.
Engineer removes the hotfix and it works again.
Engineer had some net traces but “no info was in them”
Engineer could not repro.
Engineer requested an image of the customers client and could not repro.
Where to go from here?
Problem 1 – GP edits broken.
After looking at the file associations I noted that the file associations were modified – the “%*” was missing:
Added that back in and we were good to go.
Dont think we really needed to debug it...
Problem #2
This was a fun one. In this case a debugger was the only way to determine what was going on. In a nutshell, we map a drive internally to the users profile ( you can see this in the userenv log) – and when we call CreateNestedDirectory it failed with “The system cannot find the path specified.”
The Userenv thread should be in the context of the user when we reach way down into the kernel to the object manager to pull up the namespace. You can explore this via winobj from sysinternals. Anyway, it turned out that when we went it to obtain the mapping of the obj manager at this particular time – it was done as system. So, when we asked for the E: drive it wasn’t there. Where was the bug? There was a winlogon event to play a sound – we stopped impersonating to play the sound and then never went back to set the thread token as the user again before we called in to get the obj mgr mappings.
Definitely needed to debug this one.
Problem #3
Turned out that there were a few scenarios where it worked OK.
Adjusting the "View as" settings and found at when "View As" was set to "Large Icons", "Small Icons", "List", or "Details" we experienced the issue (with it set to Classic), but did not experience the issue when set to "View As" "Thumbnails". We also tried setting the mode to "View as web page" (this is the default for Windows 2000) and were also able to perform the drag-and-drop without issues.
Resolution?
Tested the latest and greatest version of Shell32.dll and this fixed the problem.
This is what I call the "shotgun method" - not always the best way to go and sometime we dont have the option, but valid top down tshooting IMO.
So, maybe it isn’t easy to tell when to jump in and do a live debug, but with some good high level, logical troubleshooting you can get real close and maybe even be OK with a workaround.
spat
Comments
- Anonymous
July 06, 2005
The problem with drag and drop is caused by a Internet Explorer security fix. Dfs is considered to be in the Internet Zone. The solution is to add your DFS to the Trusted Sites zon in IE