Debugging Challenge - no source available

[Guest]

Hello all,

I am working on an application which uses quite a few bitmaps as skins for
custom controls.

I am getting a very difficult bug to track - my application performs quite a
few bitmap operations which use a timer to help time-slice so the UI remains
responsive. At one point, I am setting a flag to indicate to the timer that a
particular control needs to have its background refreshed. This is placed
into a list for future handling. This completes fine. Debugging in the timer
also doesn't reveal any problems, although it gets rather difficult to follow
the execution thread.

At any rate, at some, not particularly repeatable point, I press F10 and
control returns to .net/Windows and I get the error:

"A first chance exception of type 'System.ArgumentException' occurred in
system.drawing.dll Additional information: Invalid parameter used."

The problem is that I don't have any clue as to where the error is occurring
- the debugger stops at the Application.Run() line, there's no call stack, no
objects I can evaluate, I'm kinda stuck.

If I turn off exception debugging (i.e. set "When the exception is thrown"
radio-button to "Continue"), then the error changes to:

"An unhandled exception of type 'System.ArgumentException' occurred in
system.windows.forms.dll Additional information: Invalid parameter used."

In both cases, the debugger catches execution at the same point, just before
shutting the program down.

I'm looking for any pointers on steps I can take to at least cause execution
to pause at some useful point.

Thanks,
Markus Szillat

 

[Ray Cassick \(Home\)]

My guess might be that some judiciously placed debug.writeline statements
might be in order to at least help you collect some runtime data as to where
you were in the code at the time of the crash.

 

[Guest]

Thanks for the tip.

I altered the program start from:

Application.Run(new MyClass());

to:

MyClass a=new MyClass();
Application.Run(a);

And when it crashes I now have an object (a) to inspect. I also added a few
lines to tell if a particular routine (e.g. timer) was executing during the
crash, but it appears that my code is not executing at the time - I suspect
problems inside .net's painting algorithms. I suspect it may have to do with
transparent backgrounds - I previously noticed some bizarre behavior when I
tried to set a control's background to a transparent bitmap (the transparent
region is filled with screen garbage). There's a note in the help file that
transparent images are not supported. I suspect that at times that might
cause some type of memory fault causing .net to crash, but it's hard to know
for sure. I've decided to derive my own control from the label control I'm
having the problem with and override its OnPaint method with nothing, then
generate my own method to cache the label's image over my bitmap and have my
bitmap-based control just render the cached bitmap. Hopefully that will fix
the problem.

Thanks for the tip,
Markus