Winforms Question

  • Thread starter Thread starter Armin Zingler
  • Start date Start date
A

Armin Zingler

Hi,

why are exceptions in OnResize just ignored as if nothing happened?

Protected Overrides Sub OnResize(ByVal e As System.EventArgs)

MyBase.OnResize(e)

If f_Bitmap IsNot Nothing Then
f_Bitmap.Dispose()
End If

Trace.WriteLine("OnResize: before") '******* reached
f_Bitmap = New Bitmap(ClientSize.Width, ClientSize.Height)
Trace.WriteLine("OnResize: after") '******* NOT reached

End Sub

My fault was that ClientSize is zero with a minimzed Form, but
why is the exception at "New Bitmap(0,0)" just ignored? This is
a big problem because f_Bitmap still points to the previous disposed
Bitmap, which leads to an exception later.
 
Armin said:
Hi,

why are exceptions in OnResize just ignored as if nothing happened?

Protected Overrides Sub OnResize(ByVal e As System.EventArgs)

MyBase.OnResize(e)

If f_Bitmap IsNot Nothing Then
f_Bitmap.Dispose()
End If

Trace.WriteLine("OnResize: before") '******* reached
f_Bitmap = New Bitmap(ClientSize.Width, ClientSize.Height)
Trace.WriteLine("OnResize: after") '******* NOT reached

End Sub

My fault was that ClientSize is zero with a minimzed Form, but
why is the exception at "New Bitmap(0,0)" just ignored? This is
a big problem because f_Bitmap still points to the previous disposed
Bitmap, which leads to an exception later.
Click to expand...

I tried the above in VS2010 and did get an error, as expected ...

A first chance exception of type 'System.ArgumentException' occurred in
System.Drawing.dll

Parameter is not valid.
 
Am 23.03.2011 12:08, schrieb Jason Keats:
I tried the above in VS2010 and did get an error, as expected ...

A first chance exception of type 'System.ArgumentException' occurred in
System.Drawing.dll

Parameter is not valid.
Click to expand...

Thanks Jason,
I just remembered that this is the same debugging-impossible issue
on W7-64 I complained about lately. I didn't immediatelly consider
it's the same thing again. This is x86 target. If I target x64,
the exception leads to the "send error report" dialog instead of the
debugger catching the exception as you see it on your machine - and
as I expect it. No, I'm not gonna reinstall a third time. :(
I've verified 100 times that JIT debugging is enabled in VS options
and I also added <system.windows.forms jitDebugging="true" /> in
machine.config for 32 bit and 64 bit Framework. It still works well
on XP-32 but still fails on W7-64.
 
Armin said:
I've verified 100 times that JIT debugging is enabled in VS options
and I also added<system.windows.forms jitDebugging="true" /> in
machine.config for 32 bit and 64 bit Framework. It still works well
on XP-32 but still fails on W7-64.
Click to expand...

Yes, sorry, I forgot to mention I was using Windows XP (32 bit). I don't
yet have a 64-bit system to play with.

So your debugging problem has something to do with VS being a 32-bit
program running on a 64-bit O/S?
 
Am 23.03.2011 15:30, schrieb Jason Keats:
Yes, sorry, I forgot to mention I was using Windows XP (32 bit). I don't
yet have a 64-bit system to play with.

So your debugging problem has something to do with VS being a 32-bit
program running on a 64-bit O/S?
Click to expand...

I don't know if it's the change from XP to W7 or the change from 32-bit
to 64-bit, or both. I have neither W7-32 nor XP-64 to try it on. :-)

I've spent a LOT of time to figure out what's the cause by debugging
up and down the callstack, reading IL code and using Process Monitor
to watch file and registry access. I could describe what I've found
out, but I think it's expected too much to discuss it in this group.

The ultra-short version is: Whenever the exception occurs, the lowest
_managed_ function in the call stack is System.Windows.Forms.NativeWindow.DebuggableCallback.
Code returns back til this function but then it returns to unmanaged
stack frames, e.g. user32.dll!_InternalCallWinProc@20()
There the exception "gets lost" and the application continues as if
nothing happened. I can post the whole callstack and add comments if
you ask. I'd really appreciate some help!
 
Once again I was debugging all day and night long. And once
again I'm trying to make a long story short. Imagine this:

In a new Winforms application, I'm overriding WndProc.
I output all messages (WM_*) to the debug window. At startup,
47 messages are received. I'm picking out two of them:

The 8th msg is WM_GETTEXTLENGTH.
The 9th msg is WM_GETTEXT.

If I throw an exception in WndProc if Msg = WM_GETTEXTLENGTH,
the debugger catches it as expected.

If I throw an exception in WndProc if Msg = WM_GETTEXT,
the debugger ignores it.

The interesting part is that both messages are caused by
the same method: System.Windows.Forms.Control.WindowText.get()
It's IL code is:

.try
{
...
IL_0034: call int32 System.Windows.Forms.SafeNativeMethods::GetWindowTextLength(...)
...
IL_0068: call int32 System.Windows.Forms.UnsafeNativeMethods::GetWindowText(...)
}
finally
{
...
}

GetWindowTextLength causes WM_GETTEXTLENGTH.
GetWindowText causes WM_GETTEXT.

Now the 1 Million Euro question:
Even though both functions are called from the same procedure and from
within the same try-block, why can an exception in GetWindowTextLength
be caught by the debugger whereas an exception in GetWindowText not???

In both cases the callstack is:

WindowsApplication1.Form1.WndProc
System.Windows.Forms.Control.ControlNativeWindow.OnMessage
System.Windows.Forms.Control.ControlNativeWindow.WndProc
System.Windows.Forms.NativeWindow.DebuggableCallback
[transition from native to managed]
[transition from managed to native]
System.Windows.Forms.Control.WindowText.get()


This is what happens if I raise the exception in WndProc if msg=WM_GETTEXT:

1. WndProc exits straight back to NativeWindow.DebuggableCallback
skipping two stack frames because NativeWindow.DebuggableCallback has
a Finally-block.
2. After the Finally block has executed, execution returns back to
Control.WindowText.get straight after the call to GetWindowText.

I don't see the difference between these two calls. I intentionally
picked out these two messages because they *should* work equally.


I could write books about what I've tried, so, *this* *is* already
the short version.
 
Hello everybody, ;-)

Same problems in a VM on a fresh W7-64 installation.
So I can save myself this on my (physical) machine.
 
Armin Zingler explained :
Guys and girls, this is it!

http://blog.paulbetts.org/index.php...ception-user-mode-callback-exceptions-in-x64/

Me still being speechless after days and nights digging
deep into the system.
Click to expand...

Hey.. This actually bit me today :) But, you know what, changing my
app to compile to any cpu fixed the issue - maybe because I am on win7
sp1 already? So, basically VB defaulted my compile type to x86
(32-bit) - when I changed to any cpu (so now it compiled 64-bit at
runtime) then I started getting the exceptions..
 
Back
Top