CODEWITHSUNDEEP
windowsdll
DGentry
DGentry

Reputation: 16248

Strip Windows DLL debug info?

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?

Upvotes: 8

Views: 10928

Answers (5)

Chris Becke
Chris Becke

Reputation: 36026

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.

Upvotes: 6

0xC0000022L
0xC0000022L

Reputation: 21269

Ignoring for the moment the other suggestions such as getting a release version, which is valid. The tool the developers would be looking for is actually link.exe from Visual Studio (or the SDK or WDK).

If they would like you to be able to make use of a debugger together with their code they could create public PDB files for you. The options they'd want to use are:

  /PDB:filename
  /PDBSTRIPPED:filename

However, I'm afraid that you yourself can't do a lot about it. The PDB files themselves are separate files and debug information does not usually get included in binaries on modern MS compilers (though some RTTI stuff may get included, not to mention the file names and strings for ASSERT and similar macros and "functions" - which is the most likely explanation for the perceived bloat).

Note: binplace.exe from the WDK provides the same functionality as the above flags, but has a somewhat more convoluted (albeit fitting for the WDK build process) syntax.

Upvotes: 0

mox
mox

Reputation: 6314

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

Upvotes: 2

jeffm
jeffm

Reputation: 3151

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.)

Upvotes: 3

Greg Hewgill
Greg Hewgill

Reputation: 993055

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.

Upvotes: 8

Related Questions