System.drawing.dll Exception

L

linesh

Freshman
Joined
Oct 14, 2004
Messages
32
Location
Washington D.C.
Hi Everyone,
I keep getting this exception for quite sometime and maybe someone could give me some pointers. This occurs sporadically.

My application has a splash screen(form) that loads a main form. This error occurs when the main form is being loaded. The splash has a timer and after 2 seconds the main form is loaded and the splash form is hidden.
The main form has some controls which are custom-drawn (tabs, buttons). It also contains some VB6 activex controls (Interop).

I get the following errors one after another:


An unhandled exception of type 'System.NullReferenceException' occurred in system.drawing.dll

Additional information: Object reference not set to an instance of an object.


An unhandled exception of type 'System.InvalidOperationException' occurred in system.drawing.dll

Additional information: The object is currently in use elsewhere.

Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at System.Drawing.SafeNativeMethods.IntGdipDisposeImage(HandleRef image)
at System.Drawing.SafeNativeMethods.GdipDisposeImage(HandleRef image)
at System.Drawing.Image.Dispose(Boolean disposing)
at System.Drawing.Image.Finalize()The program '[2356] ZView.exe' has exited with code 0 (0x0).

Has anyone seen/experienced this before? Any suggestions would be welcome.

Thanks in advance,
Linesh
 
NullReferenceException is a common exception. It is happening because you are, as the error hints, trying to access a method/property of an object instance that does not exist.

I would be willing to be that it is one of the COM objects you spoke of. Just put some breakpoints in your app to see which object is causing the problems.
 
I would be willing to be that it is one of the COM objects you spoke of.
Click to expand...
I wouldn't be so sure.

The exception is being thrown inside System.Drawing.Dll, which means that it is being thrown in .Net Framework code, not a COM/ActiveX object or your own code. It could be a bug in the .Net Framework, or that you are feeding bad information that causes an exception to be thrown (unlikely, and would ultimately also be a .Net Framework bug), or it could be that some component of your program is interacting with the image that is trying to dispose itself and causing problems. Since the first function on the call stack is the Finalize method, the exception is not being caused by code you explicitly called, but code that is automatically run when garbage is collected (you should be disposing your own IDisposable objects, though). Thats about all I can say without seeing some code, but I would recommend you look carefully at anything that interacts with System.Drawing.Images, especially non-.Net stuff.

I would say to set the debugger to break on exceptions or add breakpoints, but that won't help much when exceptions are caught from objects being garbage collected.
 
Last edited:
marble_eater said:
I would say to set the debugger to break on exceptions or add breakpoints, but that won't help much when exceptions are caught from objects being garbage collected.
Click to expand...

I doubt the exception is occurring during garbage collection -- not too much that can go wrong there. This is a NullReferenceException which, as the name implies, is "thrown when there is an attempt to dereference a null object reference". Also, breaking on exceptions doesn't help too much since you're probably going to get the same message you already have.

What you want to do is add breakpoints before the suspected problematic section of code and make sure they are being hit. Do this until you pinpoint the exact line where the error is happening. It is most likely that you are not instantiating something before using it. The .NET compiler will, at least, force you to instantiate objects to null before you try to use them (you will still get a NullReferenceException, but the .NET compiler will warn you ahead of time). This leads me to believe that is one of your COM objects -- as those don't always play very well with .NET.
 
Mister E said:
I doubt the exception is occurring during garbage collection
Click to expand...
Take a look at the stack trace. The exception is not being thrown by the garbage collector, but it is being thrown by an object being garbage collected, specifically, an object which is finalizing. Finilization code is regular, plain old IL, just like any other .Net code, and subject to bugs and errors just like any other .Net code.

Again, look at the stack trace. The exception is being thrown by System.Drawing.Dll, meaning that it isn't user code throwing the exception (can't set a breakpoint) and you can't step into the code during debugging unless you pull up the disassembly. And, again, this is during garbage collection (implicit call to System.Drawing.Image.Finalize) so there isn't even a way to step through to where the non-user code is called.
 
Yes there is no way to step into that piece of code. Marble you are correct. I found out a solution (workaround) for the problem. I added a Sub Main to the Main Form and then instantiated the Splash screen from the Main form. Then after showing the Splash screen for about 2 seconds, I hid that (using a timer) and then loaded the Main Form by doing an "Application.Run(MainForm).
So the code looks like this:


Dim frmStart as New frmSplash
Dim mainFrm as New frmMain
frmStart.showDialog(mainfrm)
Application.Run(mainFrm)


For some reason, this works! I think the error had to with how the objects on the main form get loaded and drawn. Having my own "Main Sub" instead of starting the Splash form helped.

Again, the exact logic beats me, but the application runs and i no longer get the error message. Thanks a lot all for your replies guys.


marble_eater said:
Take a look at the stack trace. The exception is not being thrown by the garbage collector, but it is being thrown by an object being garbage collected, specifically, an object which is finalizing. Finilization code is regular, plain old IL, just like any other .Net code, and subject to bugs and errors just like any other .Net code.

Again, look at the stack trace. The exception is being thrown by System.Drawing.Dll, meaning that it isn't user code throwing the exception (can't set a breakpoint) and you can't step into the code during debugging unless you pull up the disassembly. And, again, this is during garbage collection (implicit call to System.Drawing.Image.Finalize) so there isn't even a way to step through to where the non-user code is called.
Click to expand...
 
I get same problem

I'm with marble eater. I debugged my C# code the old fashioned way with line numbers out to a text file and reran it several times. I observed that the line on which the crash occured moved around the program randomly. Then without seeing the fault I made the logical jump that it was the Garbage Collector because 1) one of the crashes was on my own formal dispose call at the end of the code 2) the fault was moving around - meaning something else was doing it not me. I then had a user execute the program one hour intervals during the day and send me all the traces. Guess what - that wierd internal .Net dispose call showed up - which is how I found this thread. I'm going to take MarbleEaters vote as a second opinion. We are pretty unanimous in this - the garbage collector can screw up your code randomly on an image dispose. Now the interesting bit - the fault happens when our graphics software takes in TIF files from Picture Publisher 10. No other paint program or file format causes the same crash. My further best guess is that the image gets misloaded in the first place somehow due to a file format issue, but thiis not discovered until the dispose hits. Anyway - I hope that further insight/guess helps someone.

Fixes - LOL. It's impossible to debug really isn't it. I thinkI will take the hint from above and frig with the code to see if I can cheat the software out of crashing. Possibly passing it between two bitmaps may work. Then again I may write a PP10 detector that forces file interchange with that program onto PNG so it wont crash. Hmmm probably the latter.

Anyway - my extra bit of advice is to try different incoming image file formats and see if that does the trick.

Finally - MarbleEater you are :cool: OK?
 
Back
Top