I'm trying to decompile the windows photo viewer DLL files to try to tweak them, such as editing speed etc. Since this wasn't possible in the registry.

When opening the files in a program such as ILSpy or dotPeek, I get a message that looks like this:

This file does not contain a managed assembly.

I'm rather new to reverse engineering things so could anyone tell me what I'm doing wrong here since the programs say it's a .NET Framework 4.5 application.

  • 1
    It means the dll was not made with .net
    – 0xec
    Jul 6, 2014 at 14:32
  • @ExtremeCoders is there any way to figure out what it was made with?
    – Paradoxis
    Jul 6, 2014 at 14:48
  • 1
    Scan it with a pe detection tool like PeiD, ExeInfo Pe, Detect It Easy etc.
    – 0xec
    Jul 6, 2014 at 14:53
  • What is the file name you're trying to decompile? Jul 9, 2014 at 7:29
  • @ThomasW. "PhotoViewer.dll" It is located under C:\Program files\Windows Photo Viewer\ on a normal windows 7 OS
    – Paradoxis
    Jul 10, 2014 at 19:29

3 Answers 3


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.

  • how do get the lmv command to work? I have downloaded the windows debugging tools, but no success.
    – kajacx
    Nov 25, 2016 at 20:55
  • @kajacx: maybe you have .NET 4, Silverlight or .NET Core? Try lmv m clr and lmv m coreclr. If nothing works, try lmv on its own. If that does not work either, let me know more details about your environment. Are you doing live debugging or do you have a crash dump file? Nov 25, 2016 at 22:06
  • @TomasWeller I don't know what half of these questions mean, I just wanted to decompile a .exe file to C# code, but now I have solved the problem in another way. Just out of curiosity, where do you even put the lmv commad? 0:008> lmv m MyApp doesn't look like standard command line.
    – kajacx
    Nov 27, 2016 at 9:39
  • @kajacx: it seems you're quite unfamiliar with the topic. 0:008> is a WinDbg prompt. You can't decompile all programs to C# code. It must be written in .NET to do that. Nov 28, 2016 at 7:22
  • Ok, so what to do when you get the message in OP?
    – not2qubit
    Feb 6, 2017 at 11:57

It's probably a native dll. You can probably decompile the main photo viewer binary (which presumably is managed code, based on your statement) to get some information about the native dll to assist in your disassembly based reverse engineering of the dll.


If your dll is native, and is less than 10 MegaBytes in size, then try to use this Retargetable decompiler.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.