The problem you face is quite common. A .NET application still loads many native DLLs. Most surprising for many people is that the .NET framework itself is native.
You can identify .NET DLLs in WinDbg using the lm v
command. In case of a managed DLL it says:
0:008> lmv m MyApp
start end module name
10310000 10574000 MyApp(deferred)
Image path: C:\...\MyApp.exe
Image name: MyApp.exe
Has CLR image header, track-debug-data flag not set
Timestamp: Wed May 21 16:34:02 2014 (537CB95A)
...
Note the line Has CLR image header
in the output. The .NET framework is also loaded in that process, but it is native and does not have such a line:
0:008> lmv m mscorwks
start end module name
79470000 79a1e000 mscorwks (pdb symbols) d:\...\mscorwks.pdb
Loaded symbol image file: C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Image path: C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Image name: mscorwks.dll
Timestamp: Tue Oct 22 03:06:42 2013 (5265CFA2)
...
There are good reasons to use native DLLs by a managed application:
- because it's already implemented and stable
- for performance reasons: maybe C++ was just faster (maybe not in your case, since you don't seem to be happy with the performance)
PhotoViewer.dll
is a native DLL, even if dotPeek says "Platform: .Net Framework 4.5". This seems to be a bug, because it also reports .NET for kernel32.dll
.
The properties Assembly platform
and Module Runtime
seem to be a bit inconsistent anyway. Here are some combinations I tried that caused results which at least would need some explanation:
- kernel32: Platform 4.5, Runtime: none
- Jigfdt.fdt100: Platform 2.0, Runtime: 1.1.4322
- Fdt.ProfibusTransformers: Platform 4.0, Runtime 2.0.50727
Another way of detecting .NET is Dependency Walker. A pure .NET assembly typically has only one dependency on mscoree.dll
while native DLLs depend on different things.
.net