Smash Windows DLL Debugging Information?

Question

I usually do not work on Windows development, and I am completely unfamiliar with the toolchain and build system. My embedded product includes some third-party Windows DLLs in its file system (which are used by the Windows machine that mounts the file system).

I have a problem: the most recent version of these DLLs has tripled compared to previous builds and they no longer fit into the file system. There are not many changes in the functionality of the DLL, so I suspect that the developers simply forgot to remove the debug symbols in this folder. I will ask them, but getting an answer often takes several days due to time zones and language differences.

Can someone explain, using simple steps for someone unfamiliar with VisualC, how to determine if the DLL contains debugging information and how to disable it?

Answer 1

You want to get release versions from developers, even if it’s a pain, because debug versions are compiled by default with disabled code optimization. Therefore, even if you somehow deleted the debugging information, you will remain with code that is not as effective as it could be. (Not to mention that there may be debugging traps and messages.)

As for determining which DLL you have, you can use Dependency Walker to find out if your DLL is debugging or releasing a version of the VC runtime library (assuming these libraries are not statically linked).

Answer 2

As a rule, the debugging information itself is created as a separate *.pdb (Program DataBase) file, and is not added to the binary file, as in unix. If the developers did build a debug version of the library, a more serious problem could be the dependency problem. If the release version of the binary refers to MSVCRT.DLL , then the debug assembly will refer to MSVCRTD.DLL (other runtime libraries are similarly called the suffix D). To find the dependencies for a particular binary, try:

 dumpbin /imports whatever.dll 

This will show all library runtime dependencies whatever.dll (note that the library names and symbols from these libraries are indicated). If you don’t see the list of dependencies you are expecting, perhaps the problem can only be fixed after the original developer rebuilds the library in the correct build mode.

Answer 3

Rebase is part of the Microsoft toolkit. In addition to setting the base address for the dll, it can strip any attached debugging information into a separate .dbg file.

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

Theoretically, you should try to determine if the dll is built for a unique base address and use this. Alternatively, choose a base address to minimize the chance of collision with any other DLL files used by your application, so that windows do not need to fix the DLL when loading. In an era when bootloaders usually randomize the load address of modules as a security feature. I'm not sure if he should worry more about setting the base address.

Answer 4

The dependency engine shows dependencies, but doesn’t delete debugging information. Use PeStudio to see both.

Answer 5

Ignoring other offers at this time, such as getting a release version that is valid. The tool that developers would be looking for is actually link.exe from Visual Studio (or SDK or WDK).

If they would like you to be able to use the debugger along with their code, they could create public PDB files for you. The options they would like to use are as follows:

  /PDB:filename /PDBSTRIPPED:filename 

However, I am afraid that you yourself cannot do much. PDB files themselves are separate files, and debugging information is usually not included in binaries for modern MS compilers (although some RTTI materials may be included, not to mention ASSERT file names and strings and similar macros and "functions", which is the most likely explanation for perceived bloating).

Note: binplace.exe from the WDK provides the same functions as the above flags, but has a slightly more complex (albeit suitable for the WDK build process) syntax.