That’s normal, I believe (dump_…).
Actually, I guess I can think of two things to try. The first, which I probably should have mentioned earlier is to try the checked build of ntoskrnl.exe and see if that has it. I guess there is no reason why it should be in one and not the other, but as it is pretty easy to try, it’s worth a shot.
The other suggestion is that, as a last resort, you can add the definition of _MM_VERIFIER_DRIVER_DATA to the ntoskrnl.pdb. The problem here is what does it looks like on Win2K? I don’t know; perhaps there’s someone this list who does, but if not, in this case, as you’re otherwise stuck and it doesn’t sound like you actually care what the actual output is, so long as it doesn’t crash WinDbg on the host, and get’s you to the point where you can do whatever it is you want to do, here’s what it looks like on 6001-x64-CHK as a place to start:
dt nt!_MM_DRIVER_VERIFIER_DATA
+0x000 Level : Uint4B
+0x004 RaiseIrqls : Uint4B
+0x008 AcquireSpinLocks : Uint4B
+0x00c SynchronizeExecutions : Uint4B
+0x010 AllocationsAttempted : Uint4B
+0x014 AllocationsSucceeded : Uint4B
+0x018 AllocationsSucceededSpecialPool : Uint4B
+0x01c AllocationsWithNoTag : Uint4B
+0x020 TrimRequests : Uint4B
+0x024 Trims : Uint4B
+0x028 AllocationsFailed : Uint4B
+0x02c AllocationsFailedDeliberately : Uint4B
+0x030 Loads : Uint4B
+0x034 Unloads : Uint4B
+0x038 UnTrackedPool : Uint4B
+0x03c UserTrims : Uint4B
+0x040 CurrentPagedPoolAllocations : Uint4B
+0x044 CurrentNonPagedPoolAllocations : Uint4B
+0x048 PeakPagedPoolAllocations : Uint4B
+0x04c PeakNonPagedPoolAllocations : Uint4B
+0x050 PagedBytes : Uint8B
+0x058 NonPagedBytes : Uint8B
+0x060 PeakPagedBytes : Uint8B
+0x068 PeakNonPagedBytes : Uint8B
+0x070 BurstAllocationsFailedDeliberately : Uint4B
+0x074 SessionTrims : Uint4B
+0x078 OptionChanges : Uint4B
+0x07c VerifyMode : Uint4B
+0x080 PreviousBucketName : _UNICODE_STRING
I don’t have any 32-bit targets running, but there isn’t anything that’s obviously 64-bit specific. In any case, what you do with this is to create a structure out of this information and put in a .c file, then, with the a copy of the ntoskrnl.pdb that WinDbg is currently using in the same directory as the .c file, execute the following (adding things such as include path as necessary:
cl -c -Fdntoskrnl.pdb <.c file>
This will add the definition of _MM_DRIVER_VERIFIER_DATA to ntoskrnl.pdb. Finally, copy ntoskrnl.pdb back to the folder which WinDbg is using as a symbol cache.
That’s the basic idea, and hopefully the definition is close enough to get by; it very well may not be, and the part that sucks is that it may be hard to figure out whether it really works or not. But, it is what it is if you don’t have any better options. In any case, it has been a while since I’ve done this, so you may have to modify it somewhat, but I think that it should work, at least as far as loading the pdb. Ideally, the checked build will have the information, and, if not, hopefully, someone can produce the actual definition of _MM_VERIFIER_DRIVER_DATA on Win2K. As Win2K was just dropped from the list of supported targets in the Server 2008 WDK, it hardly seems like trade secret knowledge at this point.
Good luck,
mm
