UST and 64 Bit Machines


Digging more into lessons learned from James’ blog on analyzing memory usage (my first two articles are here and here). Today we take a side trip into 64 vs. 32 bit. While we were working on this issue, I decided to get some UST enabled dumps of MFCMAPI so I could compare a known scenario to the customer’s unknown scenario (a great diagnostic technique). However, no matter what settings I specified in gflags, when I attached the debugger, MFCMAPI didn’t have UST enabled!

Let’s look at how gflags works. When you run the command “gflags /i mfcmapi.exe +ust”, some registry keys are created here:

HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options

Specifically, the key mfcmapi.exe is created and some values are set under it. When you launch a process, the OS matches looks for this registry key, reads the values, and uses them in setting up the process.

Of course, this didn’t work for me, so I ran Procmon to see what key the OS was looking for. Procmon showed the OS was looking here:

HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionImage File Execution Options

The key difference of course being the Wow6432Node. It turns out I had both the 32 bit and 64 bit debugger packages installed on this machine, and each comes with it’s own version of gflags. On a 32 bit machine, the 32 bit gflags sets the normal, non-wow64 key. But on a 64 bit OS, the 32 bit version of gflags gets redirected to Wow6432Node. The 64 bit version of gflags, of course, sets the non-wow64 key.

The trick here is I had run the 64 bit gflags, which set the non-wow64 key, but the MFCMAPI process was looking under  Wow6432Node. Once I ran the 32 bit version of gflags, UST worked quite nicely. Problem solved.

Except – when I launched MFCMAPI from the 64 bit debugger a strange thing happened. The OS read from the non-wow64 node. If I’ve only run the 32 bit gflags I don’t get UST. The explanation is spelled out in Mithun’s post on Image File Execution Options (IFEO)– where the OS looks depends on the bitness of the process that called CreateProcess, not the bitness of the process being launched!

So – if you’re giving someone instructions to gather dumps for you, and you want UST (or any other IFEO setting), to be safe you’re best off having them set reg keys in both places. Then it won’t matter how the process was launched, or what the bitness is.

Next: UST and long file names.

Comments (4)

  1. Hai says:

    Steve,

    These series of debugging scenario blog entries are very informative and useful. Keep up the good work!

  2. Lev says:

    absolutely agree with Hai.  Thanks Steve!

  3. jmdesp says:

    Sorry but that’s not what I see here:

    C:Program Files (x86)Debugging Tools for Windows (x86)>gflags.exe /p /full /enable myprog.exe

    Warning: pageheap.exe is running inside WOW64.

    This scenario can be used to test x86 binaries (running inside WOW64)

    but not native (IA64) binaries.

    But it’s

    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Optionsmyprog.exe that’s modified.

    BTW what I’m truly to understand is why I could not get Full Page Heap in the Wow6432 case, only normal page heap.

  4. Stephen Griffin says:

    Try setting the key under Wow6432Node as well. The point of the article was that it’s tricky and not always consistent which key will be consulted for a 32 bit app running on a 64 bit OS, so you should set both to be sure.