Ofek's Visual C++ stuff

There is a nice feature that is all but undocumented, and has next to no web presence too:  you can give your threads meaningful names.

While this is trivial in managed code, it is hardly obvious for native.  The TIB (the internal thread administration data table) does not include a name slot, so there’s not much use looking for some SetThreadName(…) API in win32.

Anyway, the MS debuggers (both Visual Studio and the WinDbg family) have a secret trap door just for that:  the exception 0x406D1388.  When raised, the debugger (obviously) gets a first-chance of handling it. This exception can carry thread-naming info, in an undocumented THREADNAME_INFO type, and the debuggers can interpret this info and internally attach that name to that thread ID.  A quick rehash of the MSDN code:

//
// Usage: SetThreadName ("CurrentThread");
//        SetThreadName ("OtherThread", 4567);
//

typedef struct tagTHREADNAME_INFO
{
   DWORD dwType; // must be 0x1000
   LPCSTR szName; // pointer to name (in user addr space)
   DWORD dwThreadID; // thread ID (-1=caller thread)
   DWORD dwFlags; // reserved for future use, must be zero
} THREADNAME_INFO;

void SetThreadName( LPCSTR szThreadName, CONST DWORD dwThreadID = -1)
{
   THREADNAME_INFO info;
   info.dwType = 0x1000;
   info.szName = szThreadName;
   info.dwThreadID = dwThreadID;
   info.dwFlags = 0;

   __try
   {
      RaiseException( 0x406D1388, 0, 
              sizeof(info)/sizeof(ULONG_PTR), (ULONG_PTR*)&info );
   }
   __except(EXCEPTION_CONTINUE_EXECUTION)  {}
}

This can be a valuable debugging aid in multi-threaded apps – which today amounts to practically all of them.

While this is hardly a hidden setting, I found myself spending too much time to find it twice already – the msdn page describing it appears low on search results, since it uses very different terminology.  So,  if only for self reference, there goes:

You can easily debug executables without source (or even symbols) in VS – just attach to the running process. You can then step through instructions and watch memory and registers as you would in regular debugging.  However, I had some process-launch issues, with a process I didn’t have the source to – so I had no running process to attach to..

Apparently you cannot launch a source-less process from within VS. The way to go is to modify a registry setting that would cause windows to launch a chosen debugger (VS for me) whenever you try and execute your destination process.

The registry key is –

HKLM\Software\Microsoft\Windows NT\currentversion\image file execution options

Add a subkey with the name of the executable to debug (e.g., notepad.exe), and give it a string value with name ‘Debugger’ and either of the values –

(1) ‘vsjitdebugger.exe’ if you want the JIT debugger-selection dialog,

(2) ‘devenv /debugexe’ if you know you’d want a new VS instance,

(3) Other debuggers of your choice – windbg, ntsd, kd, etc.   Personally, I’ve yet to encounter a situation where they’re necessary, but these do exist.

The ‘image file execution options’ key contains some more goodies, that Junfeng Zhang took the time to look up and semi-document.

Edit (1) : Gregg Miskelly elaborates on Junfengs post, then updates to VS2008.  You’ll find tons of other posts googling for IFEO, but I consider these to be the most informed.

Edit (2):  Turns out there’s a much, much easier and less destructive way – vsjitdebugger.exe can accept a process as a command line argument!

It sits at the WINDOWS/system32 folder, and running ‘vsjitdebugger.exe notepad.exe’ will do the trick.

You can create a shortcut to vsjitdebugger with your executable as an argument for extra-convenience.

Type ‘vsjitdebugger.exe -?’ for a bit more stuff (executable arguments and attaching to a running process).

$err,hr is quite useful as is, but it only knows how to interpret built-in error codes. Happily, there is an easy way to extend it, via a section in autoexp.

All it takes is adding lines of the form –

error_code_in_decimal = the_string_you_want_displayed .

For instance, paste the following code into your autoexp.dat to decode Direct3D errors:

[hresult]
;1234=my custom error code
...
; start copying from here:
2289436696=D3DERR_WRONGTEXTUREFORMAT
2289436697=D3DERR_UNSUPPORTEDCOLOROPERATION
2289436698=D3DERR_UNSUPPORTEDCOLORARG
2289436699=D3DERR_UNSUPPORTEDALPHAOPERATION
2289436700=D3DERR_UNSUPPORTEDALPHAARG
2289436701=D3DERR_TOOMANYOPERATIONS
2289436702=D3DERR_CONFLICTINGTEXTUREFILTER
2289436703=D3DERR_UNSUPPORTEDFACTORVALUE
2289436705=D3DERR_CONFLICTINGRENDERSTATE
2289436706=D3DERR_UNSUPPORTEDTEXTUREFILTER
2289436710=D3DERR_CONFLICTINGTEXTUREPALETTE
2289436711=D3DERR_DRIVERINTERNALERROR

2289436774=D3DERR_NOTFOUND
2289436775=D3DERR_MOREDATA
2289436776=D3DERR_DEVICELOST
2289436777=D3DERR_DEVICENOTRESET
2289436778=D3DERR_NOTAVAILABLE
2289435004= D3DERR_OUTOFVIDEOMEMORY
2289436779=D3DERR_INVALIDDEVICE
2289436780=D3DERR_INVALIDCALL
2289436781=D3DERR_DRIVERINVALIDCALL
2289435164=D3DERR_WASSTILLDRAWING
141953135=D3DOK_NOAUTOGEN

2289436784=D3DERR_DEVICEREMOVED
141953141=S_NOT_RESIDENT
141953142=S_RESIDENT_IN_SHARED_MEMORY
141953143=S_PRESENT_MODE_CHANGED
141953144=S_PRESENT_OCCLUDED
2289436788=D3DERR_DEVICEHUNG
;end copy.

These were adapted from macros defined d3d9.h.  Just this week I learnt you could do the same with HRESULT codes of the CLR, and of course you could do the same for your own custom error codes.

Deep inside your VS installation (%VS installation%\Common7\Packages\Debugger), hides a bag of goodies called autoexp.dat.
It is only semi-official, and almost entirely undocumented. Andy Pennell confesses its his fault,  but I suspect there’s more to it.  Admittedly, its still (as of VS2008) fragile, can easily crash the IDE, subject to the dreaded ‘syntax may change’ disclaimer, and generally half baked.   All that being said, its probably the best productivity-enhancer I came across in the Visual Studio universe.

Lacking official documentation, Avery – creator of the VirtualDub video editor/converter – did a spectacular  job of reverse-engineering it (1, 2) .

autoexp’s prominent feature is customization of native variables watch, both as tooltip and in watch windows. Ever wondered how STL containers are wired to the IDE?    How come STL vectors show their contents automatically, but native arrays require manual work?

Wonder no more – the wiring is done by autoexp. If that sounds even remotely useful to you, go read Avery’s posts now.  You’ll never watch arrays, lists or hash tables the same way again.

now off to a first tweak using autoexp.

Suppose you have a Direct3D-like matrix type:

struct MATRIX
{
	float        _11, _12, _13, _14;
	float        _21, _22, _23, _24;
	float        _31, _32, _33, _34;
	float        _41, _42, _43, _44;
};

and the IDE isn’t doing a very good job of helping you grok its contents:

Fear not!  Declare a MatrixLine type, then re-declare the matrix as a union with an array of MatrixLines:

struct MatrixLine
{float f1, f2, f3, f4; };

struct MATRIX
{
 union
 {
 struct
 {
 float        _11, _12, _13, _14;
 float        _21, _22, _23, _24;
 float        _31, _32, _33, _34;
 float        _41, _42, _43, _44;
 };
 MatrixLine line[4]; // facilitates 2d matrix visualizer in autoexp.dat
 };
};

In autoexp.dat,  under the [Visualizer] section – define a preview for each MatrixLine, and set the Matrix watch to show its MatrixLines:

MatrixLine{
	preview(#([$c.f1,f],", ",[$c.f2,f],", ",[$c.f3,f],", ",[$c.f4,f]))
	children([$c,!])
}

MATRIX{
	preview([$e,!])
	children(
            #array (
                expr: $e.line[$i],
                size: 4
					)
			)
}

and enjoy your shiny new matrix watch!