Often times, one type of problem that you might want to track down in a debugger (aside from a crash) is a particular function failing in a certain way. In the case of most Win32 functions, you’ll often get some sort of (hopefully meaningful) last error code. Sometimes you might need to know why that error is returned, or where it originated from (in the case of a last error value that is propagated up through several functions).<\/p>\n
One way you might approach this is with a conditional breakpoint<\/a>, but the SetLastError<\/em> path is typically frequently hit, so this is often be problematic in terms of performance, even in user mode debugging on the local computer.<\/p>\n On Windows Vista, there is an undocumented hook inside of NTDLL (which is now responsible for the bulk of the logic behind SetLastError<\/em>) that allows you to configure a program to break into the debugger when a particular error code is being set as the last error. This is new to Vista, and as it is not documented (at least not anywhere that I can see), it might not be around indefinitely.<\/p>\n For the moment, however, you can set ntdll!g_dwLastErrorToBreakOn<\/em> to a non-zero value (via the ed<\/em> command in the debugger) to ask NTDLL to execute a breakpoint when it sees that last error value being set. Obviously, this won’t catch things that modify the field in the TEB directly, but anything using SetLastError<\/em> or RtlSetLastWin32Error<\/em> will be checked against this value (in the context of the debuggee).<\/p>\n For example, you might see something like this if you ask NTDLL to break on error 5 (ERROR_ACCESS_DENIED) and then try to open a file or directory that you don’t have access to:<\/p>\n (The debugger is slightly confused about symbol names in NTDLL due to the binary being reorganized into function chunks, but “ntdll! ?? ::FNODOBFM::`string’+0x377b<\/em>” is part of ntdll!RtlSetLastWin32Error<\/em>.)<\/p>\n Sometimes, it can be useful to add “debugger knobs” like this to your program that can be used to enable special diagnostics behavior that might be useful while debugging something. Several other components provide options like this; for example, there’s a global variable in NTDLL named ntdll!ShowSnaps<\/em> that you can set to 1 in order to enable a large volume of debug print spew about the symbol import resolution process when the loader is resolving imported modules and symbols.<\/p>\n (Incidentally, debugger-settable global variables like ntdll!ShowSnaps<\/em> are a good example of a correct way<\/a> of using debug prints in release builds, though there are certainly many other good ways to do so.)<\/p>\n Update: Andrew Rogers<\/strong> points out that g_dwLastErrorToBreakOn<\/em> existed on Srv03 as well, though it was resident in kernel32 (kernel32!g_dwLastErrorToBreakOn<\/em>) and not NTDLL in that timeframe. As the last error logic was finally moved entirely to NTDLL in the Vista timeframe, so was the last error breakpoint hook.<\/em><\/p>\n0:002> ed ntdll!g_dwLastErrorToBreakOn 5\r\n0:002> g\r\n\r\n[...] Perform an operation to cause ERROR_ACCESS_DENIED\r\n\r\n(1864.2774): Break instruction exception\r\n - code 80000003 (first chance)\r\nntdll!DbgBreakPoint:\r\n00000000`76d6fdf0 cc int 3\r\n0:004> k\r\nCall Site\r\nntdll!DbgBreakPoint\r\nntdll! ?? ::FNODOBFM::`string'+0x377b\r\nkernel32!BaseSetLastNTError+0x16\r\nkernel32!CreateFileW+0x325\r\nSHELL32!CEnumFiles::InitAndFindFirst+0x7a\r\nSHELL32!CEnumFiles::InitAndFindFirstRetry+0x3e\r\nSHELL32!CFileSysEnum::_InitFindDataEnum+0x5e\r\nSHELL32!CFileSysEnum::Init+0x135\r\nSHELL32!CFSFolder::EnumObjects+0xd3\r\nSHELL32!_GetEnumerator+0x189\r\nSHELL32!CEnumThread::_RunEnum+0x6d\r\nSHELL32!CEnumThread::s_EnumThreadProc+0x13\r\nSHLWAPI!WrapperThreadProc+0xfc\r\nkernel32!BaseThreadInitThunk+0xd\r\nntdll!RtlUserThreadStart+0x1d<\/pre>\n