Typically, you might want to track a class of problems in the debugger (except crash) is a specific function in some way failed. In the case of most Win32 functions, usually you get some (hopefully meaningful) last error code. Sometimes, you might need to know to return the wrong reasons or sources of error (in the last case of error value by several functions spread upwards).
One possible approach is to use conditional breakpoints, but SetLastError path would normally be hit, so that in terms of performance is often problematic, even if the user mode debugging on the local computer as well.
On Windows Vista, there is an undocumented internal NTDLL hook (it is now responsible for most of the logic set last error behind), it allows you to configure a program so that the specific error code to enter when the last error debugger. This is a new feature of Vista, because there is no documented (at least anywhere that I can see are not), it may not exist indefinitely.
Now, however, you can set ntdll! G_dwLastErrorToBreakOn set to a nonzero value (ed command by the debugger), in order to see the requirements set execution breakpoints when it last error value in NTDLL. Obviously, this does not directly modify the contents of TEB in the capture field, but any content or use setlastererror RtlSetLastWin32Error will be checked (in the context of the debuggee's) based on the value.
For example, if required NTDLL when an error 5 (access denied error) interrupt, and then try to open the file or directory that you do not have access, you may see a similar situation:
0:002> ed ntdll!g_dwLastErrorToBreakOn 5 0:002> g [...] Perform an operation to cause ERROR_ACCESS_DENIED (1864.2774): Break instruction exception - code 80000003 (first chance) ntdll!DbgBreakPoint: 00000000`76d6fdf0 cc int 3 0:004> k Call Site ntdll!DbgBreakPoint ntdll! ?? ::FNODOBFM::`string'+0x377b kernel32!BaseSetLastNTError+0x16 kernel32!CreateFileW+0x325 SHELL32!CEnumFiles::InitAndFindFirst+0x7a SHELL32!CEnumFiles::InitAndFindFirstRetry+0x3e SHELL32!CFileSysEnum::_InitFindDataEnum+0x5e SHELL32!CFileSysEnum::Init+0x135 SHELL32!CFSFolder::EnumObjects+0xd3 SHELL32!_GetEnumerator+0x189 SHELL32!CEnumThread::_RunEnum+0x6d SHELL32!CEnumThread::s_EnumThreadProc+0x13 SHLWAPI!WrapperThreadProc+0xfc kernel32!BaseThreadInitThunk+0xd ntdll!RtlUserThreadStart+0x1d
(Since the binary file is reorganized as a function block, the debugger symbols in the name NTDLL a little confused, but " ntdll! ?? :: :: FNODOBFM` String '+ 0x377b "is part of ntdll! Rtlsetlastwin32 error.)
Sometimes, adding in a program like this, "Debugger knob" might be useful, these knobs can be used to enable special diagnostic behaviors that when debugging something might be useful. Several other components provide such an option; for example, NTDLL in a global variable named ntdll ShowSnaps!. When the loader module and the symbol parsing imported, ShowSnaps can be set to 1 to enable the relevant symbol resolution process of importing a large number of debug print spew.
(By the way, the debugger can set global variables, such as ntdll! ShowSnaps is to use a good example of the right way to debug printed in the published version, although there are indeed many other good ways to do this.)