It was so tricky!
We were debugging an issue with a .net application. We saw that the problem could be in a function from a module called mymodule.ni.dll. (the original module name was mymodule.dll without the ni, but we did not give it importance)
I wanted to have a look to that function that crashed to check where could it be failing: we could check the source code or we could try to disassemble it from the return address, but it's funnier to decompile it and have a look 😛
So we saved the module from the process' memory to a file...and surprisingly...when we tried to open it with ildasm or reflector, it did not work!....weird...
It was a managed file for sure (CLRheader), but none of these tools were able to see anything but the manifest file 😕
After about a thousand unsuccesful tests we asked a couple of colleagues more experienced than us on .net debugging
This assembly mymodule.ni.dll was a nativeImage!! (that's what the ni added suffix means) So even if it has a clr header, it was precompiled code, that's why these tools were not able to show anything :_)
In .net 1.1 the dump also has a reference to the not ngen-ed assembly, so we could decompile this one, but in .NET 2.0 it's not possible because we have only the ngen-ed assembly.
The next step in .net 2.0 should be to check for the assdembly in the gac or disable the ngen images and reproduce again the error to take more dumps or live debug it
That was all...now as it's already dumped to the \\brain\backup I will not forget it 😛