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