- Created a new cloud project into which I wanted to deploy an existing bit of code (a new staging service for an existing production system for testing)
- Right-click Publish… and after a few seconds of thinking deploy fails with NullReferenceException (Object reference not set to an instance of an object exception) and reports of a fatal error but no other diagnostic information
Problem was that the existing service had an HTTPS endpoint defined using a certificate that I’d not uploaded to my brand-new staging service. Deleting the endpoint (or uploading the certificate) does the trick.
We recently encountered a weird issue – using Ninject for our DI needs, in a Windows Azure Worker Role with NewRelic instrumentation. All good-practice stuff, using proven technology.
And it didn’t work.
The role wouldn’t start up, RDPing in to look at the Event Log showed horrific errors in the .NET runtime itself:
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in
the .NET Runtime at IP 000007FEF6076B81 (000007FEF6070000) with exit
Application popup: WaWorkerHost.exe - System Error : Exception
Processing Message 0xc0000005 Parameters 0x000007FEFD08718C
0x000007FEFD08718C 0x000007FEFD08718C 0x000007FEFD08718C
Faulting application name: WaHostBootstrapper.exe, version:
6.0.6002.18488, time stamp: 0x4fcaabe9
Faulting module name: ntdll.dll, version: 6.1.7601.17696,
time stamp: 0x4e8147f0
Exception code: 0xc0000374
Fault offset: 0x00000000000a0d6f
Faulting process id: 0x4a8
Faulting application start time: 0x01cd9fb18d252932
Faulting application path: E:\base\x64\WaHostBootstrapper.exe
Faulting module path: D:\Windows\SYSTEM32\ntdll.dll
Using the Ninject source code and a bit of detective work the likes of which House would be proud, we found that creating a new AppDomain on an Azure Worker Role with NewRelic installed causes a pretty horrible crash. In fact, the issue had nothing to do with Ninject at all – simply having a Worker Role whose code created a new AppDomain caused the crash.
The solution we found was to:
- Construct Ninject kernels using either a list of INinjectModule instances or a list of assemblies where the modules live – importantly do not use the Load method with a set of string filenames as Ninject will create a new AppDomain to host the assemblies while it reflects over them which causes the above crash
- In the INinjectSettings object passed to the kernel constructor, turn off LoadExtensions as this causes the same code path as above to be run through, irrespective of whether any extension assemblies exist on disk
Both solutions aim to avoid the creation of a new AppDomain and thus avoid the crashing behaviour.
While we hope it’s an issue NewRelic will resolve in due course, hopefully the above’ll keep you going in the meantime.