Caution, this blog may be ironically named

Diagnosing Non Starting .Net Applications

| Comments

Recently I’ve been working on an application that uses the Telerik Winform controls.  Today I was happy enough with it to start testing it on various environments so I performed a release build, got the non framework referenced DLLs, packaged them up into a zip and copied it to the target machine.  Happy I had everything I fired up the application on the test machine, only to be met with this dialog:


I don’t know about anyone else but this is completely useless.  It didn’t tell me anything at all about what was wrong.  So some basic debugging to start with.

  • Correct .NET version installed? – Yes.
  • Built for the correct architecture (the VM was x64)? – Yes, Any CPU.
  • Is it an unhandled exception at application start? – No, it’s the wrong dialog.
  • Google the details?  Nothing relevant.

Just a quick note on ‘Any CPU’, if we had of been using Interop during the app starting up then this could have been a real problem.  Sometimes a dying interop can take out the app bypassing the unhandled exception event.  So it is definitely worth while looking more closely at if you have interop at startup.  I would normally check this by targeting x86 and x64 independently and seeing if only one fails.

Everything appeared OK at this point so it was time for some more hardcore debugging tools.  First up was ProcMon, this a fantastic tool that provides tons of information.  It is quite easy to get lost or over awed when you first generate a log but it has an excellent filter system that is extremely powerful.

I fired up ProcMon, filtered on my process name and started my app.  The log clearly shown the problem:


(Highlighting added for emphasis of the problem.)

The log is showing the app, unsuccessfully, searching for a DLL named TelerikCommon.  It turns out that even though I had all my referenced DLLs they themselves had references and dropping in the missing one made everything work.

My next step would have been to use WinDbg to see what was going on.  WinDbg, while powerful, has an extremely steep learning curve that I’m still fighting with.  So thankfully we didn’t have to go there.

Not looking to a portion blame here but the dialog could have been better as to what the problem was.  Maybe if I’d read the Telerik documentation this dependency would have been made clear or they would have a redistributable run time you need to install.  But I wanted to keep the size down as much as possible so only grabbing the ones I need is the best way to go.