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

<p>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.</p>

<p>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?</p>

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.