.NET UI Application Crash
Hi,
We have a vb.NET client UI application which calls a number of web services.
The application is intermittantly crashing completely without any evidence of an exception etc.
The application is single threaded for the most part, the only area that deviates is a class managing serial port comms via win32 calls. (we do not use p invoke..)
I understand the most likely cause for an unexpected termination of this nature is threading - more specifically that referencing UI elements unsafely...
I can say after a very large code review that this does not take place.
Can anyone provide any advice on what might be the cause or where else we might look?
Thanks,
[686 byte] By [
NZDev] at [2008-2-18]
Trapping the exit code for the process returns -536852669.
This does not appear to be a valid exit code.Anyone have any ideas at all?
I don't think anyone can debug your complicated application remotely. You will have to post a small test that crashes, or better still, debug both the managed and unmanaged portion of your code, and look at where it crashes. You can still debug applications as before, both the unmanaged and managed portion -- attatch to the process in the debugger, and you will see how. If it is crashing in the unmanged portion you may need a tool to determine if the heap or some other resource is being corrupted -- something like purify.
The first step is always to identifiy the exact code where it crashes. After that you need to determine if it is a heap corruption -- one of the hardest bugs to fix.
I certainly would not expect any remote debugging..
We have attempted to locate the area where it crashes however this is not consistent. I have not yet had it wipe out when debug or profiling tools are attached to the process.
Has anyone encountered a cause of such a failure other than UI threading issues?
Crashing can be caused by corrupting the unmanaged heap, which happens when you write to memory outside the boundaries of an allocated object or array. I can't comment on your specific failure, but the number of possible sources for that failure, when you use PInvoke or unmanaged code, is large. You may need to use some unmanaged code diagnostic tools.
Hi Frank,
The only unmanaged code we have are win32 calls for the serial port interaction. We're not using p-invoke for the very reason that we wanted to avoid this kind of issue.
We have been unable to successfully re-produce the problem consistently.
Scripted testing does not seem to cause it.
The only clue we did have was that additional trace logging in the app prevented the crash, thus we suspected some kind of timing issue with events/threading.
We went through a careful process of reviewing all aspects of the multi threading as a result we did tighten the interface between the UI thread and the thread raising the "on scan" event.
 NZ Dev wrote: |
Hi Frank,
The only unmanaged code we have are win32 calls for the serial port interaction. We're not using p-invoke for the very reason that we wanted to avoid this kind of issue.
|
|
I'm somewhat confused by this. How are you calling Win32 APIs without P/Invoke? Do you have a COM wrapper around it, or are you going through a C++ / CLI or Managed C++ wrapper?
If you're using DllImportAttribute, then can you show your declarations?
-Shawn
You might want to make sure the win32 calls you are using were designed to be used from multiple threads. If you add locks, and the problem goes away, that is a good sign they are not designed to be used that way.
If you have searched for problems with the serial port calls, and have not found any, you might want to post again using some of the function names in the topic title. That might trigger a response from someone.
Hi,
As you have mentioned that this is a UI application and there is some portion in the code that is multithreaded.
Maybe if you are accessing the UI from different threads this may cayse problems. I have spend days of debugging while working in MFC/.NET just to see what is the problem while I access my UI through multiple threads and cant find where the problem is.
It seems that windows security model for the UI is quite strict on accessing the UI elements and objects directly from different threads. For example if you pass a reference of a textbox, or a listbox object or your from object from one thread to another. The Object cannot be accessed from the other thread, the object as soon as it is passed to other thread becomes null.
Please see if you are not doing anything like this. The best approach would be to pass your data between threads throguh simple heap variables or just use any messaging mechanism for managing your data. And only update your UI elements from the thread in which they are created, Never access UI elements created in one thread from another.I hope this heps
Regards,
Aleem
Hi Aleem,
We looked at unsafe UI thread behaviour first. The only code which updates the UI executes on the UI thread.
The communication between the UI thread and the one receiving the comms event is handled via a shared property on a synchronised class i.e. only one thread can access this class property at a time.
I may be incorrect however I thought this would be safe?
Regards,
Scott
Hi Shawn,
Below is the text from the dev who put together the serial comms class we use:
We are Platform/Invoking in the sense that we are using Interop via the "
<DllImport("kernel32.dll", SetlastError:=True)>" declaration, but I have not explicitly used any Marshalling methods such as HandleRef etc, so it is used in the simplest of senses. Because I use the "SetlastError:=True" attribute, and then test for the HRESULT error code after DLL function returns, each call is tested significantly to manage behaviour that may otherwise be deemed risky.
I think that you should look back at the past 3-5 issues of MSDN Magazine. They have in depth articles about debugging techniques for managed and unmanaged code using certain tools such as Son of Sam, etc. Lots of the techniques are for scenarios like what you have described.
Hello Scott,
Have you discovered the issue with your application, yet?
1) I would definitely recommend running your application under a managed debugger (such as cordbg), especially with the "customer debug probes" enabled (e.g. for marshalling/PInvoke checks, threading checks, etc.). You can find more info on Adam Nathan's Interop blog (Adam is a long-time member of the CLR interop team).
2) The new version of the Base Class Library [in Whidbey] is shipping with a serial port class. You can find sample code for it on this MSDN's Whidbey Sample page, or discussion on Brad Abram's blog (Brad is a member of the BCL team).
Please feel free to post back on this forum if you have more technical details of the problem, or you've discovered a solution!
Thanks,
Stephen
http://blogs.msdn.com/stfisher
