1

I'm using WinDbg to dump struct information, for example:

lkd> dt nt!_LIST_ENTRY +0x000 Flink : Ptr32 _LIST_ENTRY +0x004 Blink : Ptr32 _LIST_ENTRY

The example above shows the 32-bit version of the _LIST_ENTRY struct. The 64-bit version is larger, with Blink at 0x008.

I understand that I can debug remote systems or analyze crash dumps, as long as I load the correct symbols for those Windows versions.

My question: Is it possible to dump structs for different Windows versions than the one I am running, without debugging remotely or analyzing a crash dump?

rdvdijk
  • 4,400
  • 26
  • 30
  • "without debugging remotely or analyzing a crash dump" So you mean during live debugging? I don't think that's possible, but it is possible when analyzing a dump file. – Thomas Weller Apr 02 '14 at 13:23

2 Answers2

1

Yes so long as you have the correct symbols you can dump structs for different windows versions.

The dump will contain the windows version and signature that is expected for the symbols that must match the pdbs.

EDIT

With respect to your specific issue of debugging a 64-bit dump/process on 32-bit OS, it looks like you need to be on a 64-bit OS and use the 64-bit WinDbg.

EdChum
  • 376,765
  • 198
  • 813
  • 562
  • Can you explain how I do that? I start 'Kernel Debug', choose `Local`, point to 64-bit symbols using the `.sympath` command, but the dumped structs are still 32-bit. – rdvdijk Apr 02 '14 at 10:28
  • You either use the 32-bit WinDbg or set the `.effmach x86` to set it to be 32-bit, it is better to use appropriate version. You can point to the web symbols by calling `.symfix;.reload` this will ensure the symbols are correct – EdChum Apr 02 '14 at 10:50
  • I am on a 32-bit Windows. When I do `.effmach amd64`, then `.symfix` and `.reload`, I still get 32-bit structs. Should I switch to a 64-bit system to make this work? – rdvdijk Apr 02 '14 at 11:33
  • 1
    You should use the 64-bit version to do the debugging, I'm not sure if you need to be on a 64-bit machine though, see related:http://stackoverflow.com/questions/1342099/lost-in-windbg-with-64-bit-dump-on-32-bit-machine – EdChum Apr 02 '14 at 11:50
  • @EdChum: For running a 64 bit executable, it has to be a 64 bit OS. No 64 bit application runs on a 32 bit OS (at least for Windows at the time of writing). – Thomas Weller Apr 02 '14 at 13:21
  • @ThomasW. thanks for the clarification, I've never tried but it would make sense. – EdChum Apr 02 '14 at 13:23
  • I'll accept your answer, but I'll start a new one about dumping 32-bit structs in 64-bit WinDbg. – rdvdijk Apr 02 '14 at 13:45
  • .effmach only has an effect when you're debugging WOW64 applications, it's entirely useless when trying to look at kernel mode code or structures. For kernel mode debugging, the platform architecture of WinDbg (x86, x64, or ARM) doesn't make a difference and does not need to match the target architecture. – snoone Apr 03 '14 at 15:26
  • @snoone thanks for the info, I didn't know that I almost exclusively deal with 64-bit debugging. – EdChum Apr 03 '14 at 15:41
1

If you have a 64 bit module ( ntoskrnl.exe for example ) you can load it by "Open Crash Dump..." command and dump information.

Another way: if you have a pdb file for 64 bit module, you can use pdbdump utility

pykd team
  • 229
  • 1
  • 2
  • Cool, I didn't know that. Can any file be opened as a "Crash Dump" then? – rdvdijk Apr 02 '14 at 14:12
  • I'm not sure. All PE files can be opened. And they are mapped to address space as OS does. But there is one bug in the dbghelp.dll: data section is not mapped, so you can not see initial values for global veriables. – pykd team Apr 03 '14 at 09:21