.NET WPF MissingMethodException when launching new thread

Question

I have a WPF application with a form that, when started, invokes a custom method in a new thread.

Private Sub TestStep1_Loaded(ByVal sender As Object, ByVal e As System.Windows.RoutedEventArgs) Handles Me.Loaded
    Dim oThread As New Thread(AddressOf DisplayNextPicture)
    oThread.Start()
End Sub

Private Sub DisplayNextPicture()
    '' do stuff
End Sub

This works fine on my machine, but on a client's machine the launching of the new thread results in a MissingMethodException. I'm not sure why this would happen (and unfortunately the client is in a remote location so I'm having to debug this by slipping in trace statements and trial and error). It is definitely the DisplayNextPicture() method that is not being found, as I've been able to determine via tracing.

The only thing I can think of is that this has to do with security at the framework level. Are there restrictions on launching new threads from a WPF application?

I'm unable to catch this exception via Application.DispatcherUnhandledException so I cannot get any exception details or stack trace. The client gets a .NET runtime exception dialog with the following info and this is the only way I know the exception type:

EventType : clr20r3 P1 : testapp.exe P2 : 1.0.0.0 P3 : 49fa2234 P4 : mscorlib P5 : 2.0.0.0 P6 : 471ebc5b P7 : 1295 P8 : 14
P9 : system.missingmethodexception

Please help :)

Answer 1

The MissingMethodException is thrown by the JITer (the just in time compiler). The jitter compiles the code into assembly language one method at a time. There is some method inside the delegate method (DisplayNextPicture) that is calling a method that doesn't exist in the libraries on the target machine, which I'm guessing is running an older version of .net. Since the jitter can't find the method it blows up.

I've run into this a few times now when building on a computer with VS 2008 and 3.5 SP1 installed and then try to run on a computer with only 3.0 installed. Sometimes Microsoft will add a method to the libraries and not upgrade their major or minor versions. Often this is done in one of the .net framework service packs.

Go through the code in your delegate method and look at MSDN on any suspcious methods and double check the "Version Information" to see which framework versions are supported for a method.

You could also just have your client upgrade to the latest framework if that's possible.

Answer 2

I was having this same problem. I was calling an overload of the Dispatcher.Invoke method that didn't exist in the executing version of .Net. I found a useful comment at MSDN about the method that helped me though my problem was slightly different.

http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcher.invoke.aspx

If you are using the Invoke method try using the overload that has DispatcherPriority as it's first argument.

Answer 3

I was using VS2008, .Net 3.5 and had a similar problem starting the thread for a service. Upgrading to .Net 3.5 SP1 fixed the problem. Thanks for your help guys.

Answer 4

FWIW, I had a P9 system.missingmethodexception error that was crashing a simple application on some machines but not on others. I tracked it down to a ".WaitOne(2000)" line that was executing inside a thread. Never causes a problem on my machine, but it sure crashed on those other machines, EVEN THOUGH THE CODE WAS NEVER EXECUTED! The thread hadn't even gotten to that line. The crash was occurring when the program started up, which was really frustrating. I even had a "try..catch" around the problem line of code, and it didn't help. I stopped using the AutoResetEvent and used a variable and a "while( ! signaled ) { Thread.sleep(20); }, which was a kludge, but it worked....

Answer 5

I got a System.MissingMethodException when testing my app, targeting .NET 3.5, on Windows XP SP3. I ended up installing Visual Studio 2008 Express to try compiling the app from start. Only then, the compiler gave me the relevant error, it turned up that the method WaitOne in AutoResetEvent only had a signature with 2 parameters, thus I had to rewrite:

reset.WaitOne(1000);

to

reset.WaitOne(1000, true);

I guess that Microsoft forgot to add the first overload to the Windows XP .NET 3.5 release. Because it works, and exists, in Windows 7. Go figure.

Answer 6

Just encountered this issue when attempting to run a Windows Service (which I had written). The service would run fine on my test environment but not on a different machine.

The problem turned out to be that the troublesome machine was running Framework version 3.5 while my development machine was on 3.5 Service Pack 1. Upgrading the machine to SP1 fixed the issue.

Hope this eases someone's pain a little.