0

We have a project built with vs2010 which utilizes a .dll with managed code. I've built the .dll in vs2010, target Framework .NET 4.0 (tried Client Profile as well), which is the only option 2010 gives you to use. When I go to run it, it can't initialize and I assume it's some incompatibility...but I have no idea what it would be. Does anyone have any ideas?

Also, I have downloaded a hotfix which allows you to do Incremental Managed Builds (originally it wasn't a feature in 2010)

Thanks!

Ramon Johannessen
  • 173
  • 5
  • 14
  • And now you hope someone will produce an answer based on this information? Please describe all projects (target platform etc), details of the error, what's in the config files etc. – H H Sep 10 '10 at 15:48
  • Also, what has the incremental build got to do with anything? And did you try without it? – H H Sep 10 '10 at 15:48
  • Sorry, I didn't realize how vague the question was. I was assuming it was a problem with the managed .dll (and therefore the incremental build) because it runs fine with vs2008. Nothing else has changed as far as I know moving it to 2010. We are using Ogre 1.7, targeting windows and there is no output whatsoever for log files or anything...it never gets into main. The exact error is "The application failed to initialize properly (0xc000007b). Click OK to terminate application." – Ramon Johannessen Sep 10 '10 at 16:09
  • OK, I've determined it's not the .dll. I took out all calls to managed code in the project and am not using a managed incremental build or referencing the framework and ran it...same thing. I've rebuilt, cleaned out all intermediate files.. I see from some googling that it can often be due to not having the necessary .NET framework installed, which is not the case here. What else COULD cause this? I really don't know how else to go about pinpointing the problem...any suggestions would be more than welcome! – Ramon Johannessen Sep 10 '10 at 16:30

1 Answers1

3

Exception 0xc000007b (STATUS_INVALID_IMAGE_FORMAT) is almost always generated on the 64-bit version of Windows. Because your program is running in 64-bit mode and trying to load a DLL that contains unmanaged 32-bit code. Or the other way around.

Make sure the managed assembly was built with the Platform Target set to Any CPU. That isn't the default anymore in VS2010. Project + Properties, Build tab, Platform target setting. Be sure to change it for both the Debug and the Release configuration.

If you have no clue what DLL it might be then observe the program loading the DLL with the SysInternals' ProcMon utility.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • A setting in Linker-Advanced called "Target Machine" is set to Machinex86, which is correct. Is that the setting you're talking about...I couldn't find the one you were referring to. Also, I did a Dependency Walker and it came back with 3 missing .dlls: MSVCR90D.DLL, IESHIMS.DLL, & WER.DLL. And it said there was "Import/Export Mismatch or Load Failure" for: OGREMAIN_D.DLL & OIS_D.DLL. Perhaps I have to build the Ogre stuff locally... – Ramon Johannessen Sep 10 '10 at 17:12
  • So, does it run on a 64-bit version of Windows? No, I was talking about the C# project setting. Which shouldn't matter with that target machine setting. Dependency Walker isn't a good tool anymore, it has trouble with the side-by-side cache, try ProcMon to find the trouble maker. Also, don't deploy the debug build, you cannot distribute msvcr90d.dll – Hans Passant Sep 10 '10 at 17:21
  • Not sure about 64bit, don't have one available atm. The C# project was correctly set. I'll figure out how to use ProcMon now, thanks for the help btw. – Ramon Johannessen Sep 10 '10 at 17:43
  • OK, I'm having a heck of a time figuring out how to use procmon to find which one it is. Any tips? – Ramon Johannessen Sep 10 '10 at 18:46
  • File + Save. Copy the file to a file sharing service so we can take a look at it. – Hans Passant Sep 10 '10 at 18:55
  • So I run ProcMon, run the project.exe, and quick do a capture in ProcMon? is that right? – Ramon Johannessen Sep 10 '10 at 19:46