Mouse Event problem in Quickwin

[andrew_4619]

I have a problem with a Quickwin application. It is an application I have worked on and regularly updated for many years that has suddenly become unstable. I have mouse events registered against a couple of child windows. When I make a mouse click on the window the programs crashes with a stack dump.

Under debug the program generates an exceptions like below:

First-chance exception at 0x7769fb81 in fil70.exe: 0xC0000008: An invalid handle was specified.

The stack at this point is as below.

ntdll.dll!7769fb81()        

[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]

ntdll.dll!7769fb81()        

KernelBase.dll!74dd0fa2()

fil70.exe!_for__release_lun()  + 0x1bc bytes 

fil70.exe!_GETUNITQQ()  + 0x4e bytes         

fil70.exe!_DeReferenceGetUnitPointer()  + 0x13 bytes          

fil70.exe!__QWGChangeMouseStatus()  + 0x12c bytes         

fil70.exe!__QWGraphWndProc@16()  + 0x338 bytes

 If I ignore the exception (I will get three or four more that are the same) execution control drops into the correct call back function that was  registered against the mouse event and also return correct parameters for the event (unit, button event ,keystate,  position).

I am currently using Intel(R) Visual Fortran Composer XE 2011 Update 9 with Integration for Microsoft Visual Studio* 2010, 12.1.3526.2010. I was planning to buy the update to the  latest level but I don’t expect that to fix anything.

I am running on W7 Professional x64 SP1  by the way.

Any ideas what I can do to resolve this? I

[andrew_4619]

Hi IanH,

There is some logic in your comment, I sort of thought the same at one point in this saga but I do not think it is the case. The 'normal' behaviour on this machine is now to pop the "windows has encountered a problem and is looking for a solution" followed by either a lockup or a crash dump dependant on the direction of the wind at the time. At the moment if I catch the first exception in windbg step through it (and then dump the debugger the program will then opperate normally. It run fine on other machines running the same OS (win 7 X64) so I can only assume it is some rogue interaction with this machine. 

There in lies a thought because I know that if i continue in the debugger I will get the same exception again and again but this does not result in a fatality. does windows 7 give the first exception special treatment.

As a work around for the time I might look to see if I can handle these mouse events via the windows api rather than quickwin.

[Bernard]

>>>I have just discovered that when I run the program today it does into debug at the first mouse event (exception) but if I then detach the debugger the programs runs OK without crashing for hanging>>> Yes it is so because windbg was set as a default postmortem debugger and it will break in on very broad range of the exception.Actually you can control this range. <<>> I thought that you have the handle ID.For !htrace command you can obtain the handle with the help of Application Verifier. Please read windbg help there you can find !handle command description(I'm at work now I can not download windbg).Before using !handle load kdexts.dll or check if it has been loaded with the command .chain . Regarding GDI debugging(obtaining handle to GDI objects) afaik you need to load gdikd.dll which is not supported under Win7.Have you tried spy++ utility I do not remember if this tool can gather a handle to GDI objects. Try this tool it will collect and display GDI handles : http://www.nirsoft.net/utils/gdi_handles.html

[Bernard]

Why my posts are queued for approval?

[Bernard]

>>>!handle handle_id - how do I know what the handle id is? I only know the value of the windows handle as I inquired it using GETHWNDQQ in my app. What to I need to trace with !htrace? >>>

I have already posted the answer to your question , but the message is waiting for admin approval.

IIRC  !handle won't collect GDI related handles in order to do this you must perhaps load specialized gdiexts.dll , but this file is not maintained for Win7 compatibility as a problem workaround I would recommend you to use this tool : http://www.nirsoft.net/utils/gdi_handles.html

>>>This problem will come back I think so I need to understand using windbg better>>>

It is quite possible and if you are developing production code you must know how to use windbg.If you want go deeper please read this book "Advanced Windows Debugging".

[Bernard]

>>>Is it possible that you are responding to an "expected" exception?  A first chance exception is not necessarily in itself an error - that just means that the operating system informed the debugger that an exception occurred>>>

Yes that is true.When your app runs under debugger and  the debugger will see first any exception beign thrown and it is given a chance to handle this exception.If the debugger for example does not handle the exception then the program's SEH will try to handle the exception by using registered handlers.If the the registered handlers are not able to handle the exception the debugger is renotified about the error this is called second chance.

[andrew_4619]

Thank iliyapolak I had a prost that had the awaiting approval message also and 2 days later it still hasn't shown up. Anyway thanks for your help I needed a quick fix so I made some user inteface changes which eliminated the mouse call back functions and made some imnprovement, so I don't have a problem at the moment. I have learned quite a few things this week, thanks for the help. I have a side project now to learn a few more tricks!

[andrew_4619]

I see the missing posts now. I will study them further as a learning project. I 'fixed' the problem by some user interface improvements that eliminated the mouse event callbacks. Thanks for your help it is most appreciated.

[Bernard]

app4619 wrote:

I see the missing posts now. I will study them further as a learning project. I 'fixed' the problem by some user interface improvements that eliminated the mouse event callbacks. Thanks for your help it is most appreciated.

Glad to hear that you were able to solve your problem.I would like to advise you to learn more about the debugging.Please follow this link where you can find the case of hung window http://blogs.msdn.com/b/ntdebugging/

[Bernard]

@app4619

I'm posting very interesting link about the GDI debugging http://www.osronline.com/article.cfm?id=173