Verifying if a dll is compiled debug or release mode

[luftwaffe]

Hi There,

I would like to know how it is possible to verify if a dll was compiled with debug information or release using unmanaged windows/c++.

I tried all the ways I could imagine including checking the IMAGE_FILE_HEADER for DEBUG_STRIPPED (that is not of help since debug information is stripped from non-debug builds and debug builds with external .dbg file - what is not necessarily present), checking the debugger path, the existence of the debugger instance, loading the dll and checking the IMAGE_DEBUG_DIRECTORY. No success...

Can somebody tell me how to do this?

A few lines code would be highly appreciated, it must be easy like just loading something (tried PE 0x52 2 bytes but that is the same as DEBUG_STRIPPED) what I have not managed to figure out.

You help would be highly appreciated.

Cheers

[OReubens]

The presence of debug info does not guarantee a DLL was built with debug settings. It is perfectly possible to build a release version WITH debug info. And you can also make a debug build without debug info (or strip it off).

Release dll's with debug info can be handy if a customer is having problems and the default memorydumps provide inadequate information.

Other than that, there is no difference between a debug and release dll. Depending on the situation you could maybe figure out it's a debug build by checking if it's importing the release or debug version of the CRT and/or MFC, but this again is no guarantee. You can make debug builds that import the release version of the CRT and otherwise (although it's uncommon to do so).

[luftwaffe]

Hmm... and, what do you do if it does not include anything just provides a printf for example?

[VictorN]

You can look at VERSIONINFO Resource os the DLL (if it exists) and check its FILEFLAGSMASK and FILEFLAGS values...

[cilu]

What are you trying to accomplish? Why do you need that kind of info?

As ORubens said, DEBUG and RELEASE are just a set of configurations used for building the project. There is no specific setting that a build a "DEBUG" or "RELEASE". The term release comes from the fact that is the version supplied for clients, and usually this doesn't include debug information. So, again, what do you try to do.

[OReubens]

You can look at VERSIONINFO Resource os the DLL (if it exists) and check its FILEFLAGSMASK and FILEFLAGS values...

the VS_FF_DEBUG flag is a hint only and no guarantee... you'd be surprised to see how many finished products ship with modules with this flag set.

This happens mainly because plenty companies compile release builds WITH debug info, keep the exe's/dlls separate but build their master CD's by copying the exe/dll and stripping out the debug info.
This means they have small release exes and have identical copies with debuginfo in case something goes wrong. A lot of the stripping tools leave this flag as is (and rightfully so, since the stripping tool again can't know if it's a release build with debuginfo or an actual debug build).

[VictorN]

the VS_FF_DEBUG flag is a hint only and no guarantee... you'd be surprised to see how many finished products ship with modules with this flag set.

I agree with you!
And there are many products that don't have Version resource at all!

[OReubens]

Even microsoft products. Violating their own "works for windows logo program" :-p

[Ajay Vijay]

One idea is to check if the executable links with Debug versions of VC, MFC, ATL. For example, if it has dependency with MSVCRTD.DLL, then your executable is debug build.

You can use Dependency walker to check that.

To programmatic ally identify you need to use DbgHelp functions.

[pgoel]

Hi There,

I would like to know how it is possible to verify if a dll was compiled with debug information or release using unmanaged windows/c++.

I tried all the ways I could imagine including checking the IMAGE_FILE_HEADER for DEBUG_STRIPPED (that is not of help since debug information is stripped from non-debug builds and debug builds with external .dbg file - what is not necessarily present), checking the debugger path, the existence of the debugger instance, loading the dll and checking the IMAGE_DEBUG_DIRECTORY. No success...

Can somebody tell me how to do this?

A few lines code would be highly appreciated, it must be easy like just loading something (tried PE 0x52 2 bytes but that is the same as DEBUG_STRIPPED) what I have not managed to figure out.

You help would be highly appreciated.

Cheers

Hello

Verifying is very simpler using Reflector.exe, Open this tool, Drag dll into this tool, Right click on dll and say Disassemble,

It shows the assembly information with which it was build
For debug mode, Attribute shown are as follows : -

[assembly: Debuggable(DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.EnableEditAndContinue | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.Default)]


For release mode, Attribtue shown are as follows : -
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]


Here is an full fledged example of attributes : -

DebugMode dll

[assembly: AssemblyVersion("1.0.8.0")]
[assembly: AssemblyProduct("XYZ")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCopyright("All rights reserved.")]
[assembly: AssemblyCompany(" Corporation")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyTitle("XYZ")]
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.EnableEditAndContinue | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.Default)]
[assembly: CompilationRelaxations(8)]
[assembly: RuntimeCompatibility(WrapNonExceptionThrows=true)]
[assembly: AssemblyFileVersion("")]
[assembly: Guid("")]
[assembly: ComVisible(false)]
[assembly: CLSCompliant(true)]
[assembly: AssemblyTrademark("")]

Release Mode dll

[assembly: AssemblyVersion("1.0.8.0")]
[assembly: AssemblyProduct("XYZ")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCopyright("All rights reserved.")]
[assembly: AssemblyCompany(" Corporation")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyTitle("XYZ")]
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
[assembly: CompilationRelaxations(8)]
[assembly: RuntimeCompatibility(WrapNonExceptionThrows=true)]
[assembly: AssemblyFileVersion("")]
[assembly: Guid("")]
[assembly: ComVisible(false)]
[assembly: CLSCompliant(true)]
[assembly: AssemblyTrademark("")]

As you can see the only difference in Debuggable Attributes

Regards
Aracus

[Paul McKenzie]

Hello

Verifying is very simpler using Reflector.exe, Open this tool, Drag dll into this tool, Right click on dll and say Disassemble,

An unmanaged DLL doesn't have all of that stuff you posted. That reflector tool is probably only meant for .NET DLL's.

Regards,

Paul McKenzie

[OReubens]

One idea is to check if the executable links with Debug versions of VC, MFC, ATL. For example, if it has dependency with MSVCRTD.DLL, then your executable is debug build.

You can use Dependency walker to check that.

To programmatic ally identify you need to use DbgHelp functions.

I already suggested that, but it's no guarantee... while the default 2 build configurations of VC are to make a debug build that links to the debug versions of MFC/CRT and a release build that links to the release versions of MFC/CRT this is by no means a requirement.

It's perfectly possible to make a full debug enabled exe that links to the release versions of MFC/CRT and you can also make a release exe that links to the debug versions of the MFC/CRT libs.


It's unlikely you'll ever need the 2nd type (release exe, debug MFC/CRT) but the 1st (debug exe, release MFC/CRT) is most definately usefull for debugging your code without requiring the customer to also install debug versions of the CRT/MFC (which I'm not even sure you're allowed to do as I think they're not redistributable).

[Ajay Vijay]

Well then, there is practically no way of finding the the Executable is a Debug build or a release build.

• The VERIONINFO does not give information.
• DEBUG macro may be defined in Release build, and may not be defiend in DEBUG build.
• You may have Debug/Release build (with DEBUG defined, or not defined), and may link to either Debug or Release DLL. Furthermore, few linked DLLs may be Debug versions, few others might be release versions.
• IMAGE_FILE_HEADERs also do not give exact information.
• The OS may itself be running in Debugging mode!