Shaun Xu

The Sheep-Pen of the Shaun


News

logo

Shaun, the author of this blog is a semi-geek, clumsy developer, passionate speaker and incapable architect with about 10 years’ experience in .NET and JavaScript. He hopes to prove that software development is art rather than manufacturing. He's into cloud computing platform and technologies (Windows Azure, Amazon and Aliyun) and right now, Shaun is being attracted by JavaScript (Angular.js and Node.js) and he likes it.

Shaun is working at Worktile Inc. as the chief architect for overall design and develop worktile, a web-based collaboration and task management tool, and lesschat, a real-time communication aggregation tool.

MVP

My Stats

  • Posts - 122
  • Comments - 622
  • Trackbacks - 0

Tag Cloud


Recent Comments


Recent Posts


Archives


Post Categories


.NET



One of my project needs a C++ assembly for data encrypt and decrypt. We built that assembly from Visual Studio 2013 and tested in local machine. Everything ran well. But when I published to Microsoft Azure Website, it failed.

We spent half a day to get it resolved and I think it's good to write down what we tried for future reference.

 

Bad Image Format Exception

The first exception we met is BadImageFormatException (Exception from HRESULT: 0x8007000B). This is a common exception when an Azure application tried to load a C++ assembly. In azure our application are deployed in x64 Windows system. So if your C++ assembly was built in x86 you will see this exception.

One resolution is, if you are building a web application deployed under IIS, you can specify 'Enable 32bit Application' in the advance setting of your application pool.

image

If you are deploying your application under Azure Website, you can login the management portal and switch your Website to 32bit mode if its web hosting mode is standard. This will be the same as turning Enable 32-Bit Application to True.

image

Unfortunately we cannot change it since we also need some other assemblies in x64 mode. So we need to make sure the C++ assembly we built was x64.

 

Check Assembly x86 or x64

There are a lot of questions in StackOverflow asking how to find a DLL was compiled as x86 or x64. You can use DUMPBIN with /headers or /all flag. It will print "machine (x86)" or "machine (x64)".

If you have Cygwin installed, or have Linux or Mac system available, you can use "file" command to test the assembly more quickly.

Below I'm using x86 and x64 version of Internet Explorer as an example. As you can see for x86 assembly it returned "PE32" while x64 returned "PE32+".

image

 

File Not Found Exception

After we ensured our C++ assembly was built in x64 and published to Azure, we got another exception said

"System.IO.FileNotFoundException (Exception from HRESULT: 0x8007007E)". In some articles they said this is because your application cannot find the assembly and you'd better put it into %windir%\system32. You can try and if it still said "FileNotFoundException", this is mostly because the assembly depends something that are missing on your machine.

In order to check which were missing we ran Dependency Walker on azure machine and it reported MSVCP120D.DLL and MSVCR120D.DLL were missed.

IMG_0113

These DLLs are included in Visual C++ Redistributed Package. But note that both of them with "D" at the end of the name. That means they need some debug mode VC++ assemblies. These should not be necessary in production environment and the reason our assembly needs is because we built in debug mode.

Now the resolution is clear, build C++ assembly in x64 release mode and published, then everything works smoothly.

 

Summary

Load C++ assembly from .NET project is very common. But it often introduces some problem once we published to Azure while worked well in local. In this post I talked about what I met and how I solve this kind of problem. Basically when working with C++ in Azure, we need to keep in mind

1, Is it built in x86 or x64?

2, Is it built in release or debug?

3, Is the hosting environment support x86?

And in order to find the problem as early as possible, we'd better have a dedicate local test machine

1, Windows Server x64 (English), 2008 R2 or 2012 based on what we need.

2, .NET Framework 4 or 4.5.

3, DO NOT INSTALL Visual Studio or any other development packages.

 

PS: Happy Chinese New Year!

 

Hope this helps,

Shaun

All documents and related graphics, codes are provided "AS IS" without warranty of any kind.
Copyright © Shaun Ziyan Xu. This work is licensed under the Creative Commons License.

Comments

No comments posted yet.
Post A Comment
Title:
Name:
Email:
Comment:
Verification: