Strip Windows DLL debug info?

Question

I normally don't work on Windows development, and am completely unfamiliar with the toolchain and build system. My embedded product includes some Windows DLLs from a third party in its filesystem (which are used by a Windows machine which mounts the filesystem).

I have a problem: the most recent release of these DLLs have tripled in size compared to previous builds, and they no longer fit in the filesystem. There have not been many changes in the functionality of the DLLs, so I suspect the developers simply forgot to strip debug symbols in this drop. I will ask them, but getting an answer often takes days due to timezone and language differences.

Could someone explain, using simple steps for someone unfamiliar with VisualC, how to determine if a DLL still contains debugging information and how to strip it out?

Answer 1

Generally the debug info itself is built as a separate *.pdb file (Program DataBase), instead of being appended onto the binary as in unix. If the developers did indeed build a debug version of the library, a more serious problem might be that of dependencies. If a release version of a binary links to MSVCRT.DLL, then the debug build would link to MSVCRTD.DLL (other runtime libraries are similarly named with the D suffix). To find the dependencies for a particular binary, try:

dumpbin /imports whatever.dll

This will show all the runtime dependencies for the library whatever.dll (note that both library names and symbols from those libraries are listed). If you do not see the list of dependencies you expect, there is probably a problem that can only be fixed by having the original developer rebuild the library in the proper build mode.

Answer 2

Rebase is part of the microsoft toolset. In addition to setting the base address for dlls it can strip any attached debug info into a seperate .dbg file.

rebase -i 0x10000000 -a -x .\ -p 

You should theoretically try and determine if the dll is already building to a unique base address and use that. Alternativly, choose a base address to minimise the chance of collision with any other dlls used by your application so that windows does not have to patch up the dll when loading it. In an age where loaders routinely randomize the load address of modules as a security feature Im not sure that its worth bothering specifically setting the base address any more.

Answer 3

You'll want to get the release versions from the developers, even if it's a pain, because debug versions are by default compiled with code optimization disabled. So even if you somehow stripped out the debug information you would be left with code that's not as efficient as it could be. (Not to mention whatever debug traps and messages might be in there.)

As far as determining what kind of DLL you have, you could use the Dependency Walker to see if your DLL is linked to the debug or release version of the VC runtime library (assuming those libraries are not statically linked.)

Answer 4

Dependency walker does show the dependencies but not whether the debugging information has been stripped. Use PeStudio to see both.