views:

37

answers:

3

Read a ton of material on this one and still cannot find a workable solution...

We have a "Hello, World1" app--one text block on a MainWindow--built and tested with VS2010 (C#). Target version is set to .NET 3.0. When "deployed" on a .NET 3.0 (SP2) system the app fails on startup. It fails in the call to InitializeComponent() in the MainWindow. The error is basically a dump.

When the same app is put on a system with .NET 3.5 it works flawlessly.

Note all the modules loaded during the debugger (in VS2010) indicate dll being loaded are for .Net 2.0. V2.50727.

Can't figure out how to identify what's causing the load problem. thoughts, strategies, tools, suggestions?
(This is actually holding up a deployment.)

PS. Upgrading to V3.5 in the near future is NOT and option--should be, but it's not.

A: 

have you checked the target cpu configuration?

brian brinley
32-bit WindowsNT .Net 3.0 SP2 (yes)
jon
A: 

You may want to note which versions of .Net are installed, as well as which Service Packs.

As the Microsoft download page says, .Net 3.5 also updates .Net 3.0 and .net 2.0.

Also, check your references. If you're referencing a library that depends on .Net 3.5 or a .Net 3.0 Service Pack, that could cause the error you're seeing.

Finally, I recommend Sysinternals Process Monitor and Process explorer to see exactly which dlls are loaded.

cofiem
Tried to capture the exception information using an UnhandledExceptionHandler. Tried to write to both a console and a log file. No luck--same error message. (Both console and logging test under VS2010.)
jon
SOunds like you may need to use process monitor, run the program wait for the crash, close the program. Then have a look at the process monitor logs, particularly the loaded dlls.
cofiem
+1  A: 

Don't guess at the cause of the error, let .NET tell you. Write an event handler for AppDomain.CurrentDomain.UnhandledException and display or log the value of e.ExceptionObject.ToString().

You may need to know the InnerException as well in this case since the constructor failed. Cast e.ExceptionObject to Exception. If you can't make sense of the stack trace and the exception message then copy/paste it into your question.

Hans Passant
Nice suggestion, did not work though--same result.
jon
Have you tested it? Throw an exception right after setting the event handler. Next step is to get a debugger on that machine.
Hans Passant
Yeah, I tested both the console and logging versions. They work fine. The "Send Error Log to Microsoft Popup" says I have a E0434F4D exception. Reading suggests incompatibility with CLR (also looks like a nasty problem). Do you have a preferred debugger?
jon
That's the code for a managed exception. The kind that the UnhandledException event reports. If you are sure that your event handler works then it might be dying too soon, even before Main() runs. Do make sure you subscribe the event handler on the first line of Main(). And get that debugger.
Hans Passant
All UnhandledException have the same code? (That would not be very useful.)
jon
All managed exceptions indeed have the same underlying Windows exception code. Finding out *what* managed exception got unhandled is of course the key.
Hans Passant
As it was a WPF app, I subscribed in the static constructor for MainWindow. Do you think putting in in App would really create a different result? (Working the debugger issue now.)
jon
The windows event log may have more info (or at least other error codes to search for).
cofiem