Resolving Symbols Manually on Windows CE (ADDRESS --> SYMBOL)

re: Resolving Symbols Manually on Windows CE (ADDRESS --> SYMBOL)

Steve Meredith — Thu, 03 Mar 2005 03:41:00 GMT

Great couple of blog entries!

This paragraph is a little confusing:

“The main thing you have to be careful about is recognizing addresses that are inside process slots, and converting them to slot 0 addresses. Address 0x09EE5678 is inside devmgr.dll, not device.exe.”

Can you explain how you got to that conclusion?

re: Resolving Symbols Manually on Windows CE (ADDRESS --> SYMBOL)

Sue Loh — Thu, 03 Mar 2005 04:31:00 GMT

Good question. The address 0x09EE5678 does fall inside the slot where device.exe is loaded, which you can tell by seeing that device.exe is loaded at 0x08000000. However, the first clue that it's not from device.exe is that it's in the top of the slot, not the bottom. If you remove the slot part of the address, or in CE terms if you "unmap" the address, 0x09EE5678 becomes 0x01EE5678. EXE code & data loads at the bottom of the slot, while DLL code & data loads at the top. So, an address like 0x08005678 is pretty much guaranteed to be inside device.exe, while an address like 0x09FF5678 is almost guaranteed to be inside a DLL that has been loaded by device.exe. It's actually possible that both addresses are part of something else -- heap allocations, stack, virtual allocations -- but not very likely.

So, given that, what you can do is look through the DLLs I listed and see which one is closest to the "unmapped" address, 0x01EE5678. And guess what, I should have been working more carefully, because that's not devmgr.dll after all. I thought it was, but I goofed because devmgr.dll loads in slot 1. I did the math wrong. 0x01EE5678 doesn't fall inside devmgr.dll; it doesn't fall inside any of the DLLs I listed. Using "Price is Right" matching, the closest match is kbdmouse.dll. Except if you look at the Image Address Range that I pasted from the Modules & Symbols window, you can see that kbdmouse.dll doesn't go that high.

If I was really slick, what I should have done was shown two DLLs listed for the same parts of slot 0 & 1. If there was a "foo.dll" that loaded into Image Address Range 0x01EE0000-0x01EE9FFF (which I chose because it exactly matches devmgr.dll, but is in slot 0 instead of slot 1), then the example address I was using, 0x09EE5678, would fall inside foo.dll.

Sorry about that! Good catch!

Sue

re: Resolving Symbols Manually on Windows CE (ADDRESS --> SYMBOL)

Mike Dimmick — Thu, 07 Apr 2005 10:51:43 GMT

A note for a tool I've found useful - if you don't have the .map but you _do_ have .pdbs, you can use John Robbins' CrashFinder from http://www.wintellect.com/about/instructors/robbins/code.aspx to find the function, and if you have full symbols (rather than stripped) the source line as well.

CrashFinder was written for the desktop but since CE uses the Portable Executable format too, it works fine.

Disassembly - If you don't have COD files

sloh — Tue, 12 Apr 2005 21:39:58 GMT

Another interesting trick I recently learned -- if you don't have the COD files, you can still figure out what line of disassembly the address corresponds to, by doing "dumpbin /disasm" on the module. It won't tell you the source code, but you can at least see the disassembly that way.

?????????????????????????????? » Profiling on Unix, Windows and WinCE

?????????????????????????????? » Profiling on Unix, Windows and WinCE — Mon, 18 Dec 2006 17:56:14 GMT

PingBack from http://blog.hubert.tw/2006/12/18/182

Troubleshooting guide - part 2

HoppeRx - the cure for your ailing device — Tue, 21 Apr 2009 17:09:40 GMT

Below is the second half of a well executed document from guestRx: Bulent Elmaci. Bulent has worked with

Sue Loh s blog Resolving Symbols Manually on Windows CE ADDRESS | Wood TV Stand

Sue Loh s blog Resolving Symbols Manually on Windows CE ADDRESS | Wood TV Stand — Wed, 03 Jun 2009 00:54:55 GMT

PingBack from http://woodtvstand.info/story.php?id=51754