Windows 7 - need more debug

[davidgraham]

When I run my program within Microsoft Visual Studio it works fine but when I run the compiled version it hangs.
It is difficult to track where the problem is occuring.
I have been opening & writing and closing a text file so I can create a log of where I have been.
I think I have tracked where the problem is occurring, it's in a routine that gets mouse key presses and keyboard characters.
Do you have any suggestions on to how I can add more debugging or run it in a mode where I can get more debug.

The program worked in Windows XP, the problem occurs when running in Windows 7.

Thanks

[Steven_L_Intel1]

There is a known problem with QuickWin support on Windows 7 - my guess is that you are running into that. We have a fix which we can provide through Intel Premier Support. Please open an issue there and ask that the issue be assigned to me (Steve Lionel) - I'll get you the fix.

[davidgraham]

Steve,
I had a problem with the link to Intel Premier Support so emailed to quadsupport@mailbox.intel.com hopefully you will receive it.
The project is not QuickWin but is a Windows Application.

The program says 'not responding' and goes into an endless loop when checking for mouse or keyboard entry.

[Steven_L_Intel1]

If it is not a QuickWin application, then the fix I have does not apply to you. I suggest posting relevant parts of the code, or the whole project here so that Windows programming experts can look at it.

What problem did you have with the link?

[davidgraham]

Steve,
The problem with premier support - I got the message "we are unable to authenticate your access.." It mentioned the username & password but there was no where to enter it.

Here is the code that I think is giving the problem. It should come out then the mouse or keyboard is pressed. Sometimes it works, other times it never comes out hangs - it says 'not responding'. It is old code that had been around for >10 years (I didn't write it).

It works OK with cvf on Windows XP, not cvf on Windows 7. Therefore I upgraded to ivf to investigate the problem. It works in ivf in Visual Studio in Windows 7, it doesn't work running the compiled exe in Windows 7.

Let me know if you need more information.

Thanks


SUBROUTINE LOCATE (xin,yin,itran,I)
! -----------------------------------
! xin x coord
! yin y coord
! itran - not used
! I - return - key pressed

use grad_inc

include 'cvfact.gcb' ! x2Efact,y2Nfact

type (T_MSG) msg
type (T_POINT) pt

INTEGER*4 xin,yin,itran,count
INTEGER*2 I,pi(2),po(2)
REAL*8 DE,DN
CHARACTER c7*7,c9*9
logical*4 lret

count=0
call DebugLocation ('In')

call cv_mm2mouse (xin,yin,pi(1),pi(2)) ! real world to screen coords
pt%x=pi(1)
pt%y=pi(2)
lret=ClientToScreen(hWndMain,pt)
lret=SetCursorPos(pt%x,pt%y)
! CHECK MOUSE FOR MOVEMENT/BUTTON
80 continue
call DebugLocation ('PeekMessage in')
lret=PeekMessage (msg,hWndMain,WM_MOUSEFIRST,WM_MOUSELAST,PM_REMOVE)
if (lret) then
write (c7,'(I7)') msg%message
call DebugLocation (c7)
select case (msg%message)
case (WM_MOUSEMOVE)
call DebugLocation ('MouseMove')
po(1)=LOWORD(msg%lParam)
po(2)=HIWORD(msg%lParam)
IF (PO(1)/=PI(1).OR.PO(2)/=PI(2)) THEN ! cursor moved
i=0 ! return
goto 400
endif
case (WM_LBUTTONUP)
call DebugLocation ('LButtonUp')
i=32 ! space
goto 500
case (WM_RBUTTONUP)
call DebugLocation ('RButtonUp')
i=184 ! f9
goto 500
end select
endif

call DebugLocation ('PeekMessage out')
! CHECK KEYBOARD FOR CHARACTER INPUT
85 CALL CHKCH (I) ! check for key press
write (c9,'(A,I3)') 'ChkCh ', I
call DebugLocation (c9)
count=count+1
write (c9,'(A,I3)') 'Count ', count
call DebugLocation (c9)
IF (I==0) GOTO 80 ! no key press try again
CALL GETCHA (I) ! get key pressed
call DebugLocation ('GetCha')
IF (I>96.AND.I<123) I=I-32 ! change lower case to upper case
IF (I<=95) GOTO 500 ! normal key
IF (I>=177.AND.I<=190) GOTO 500 ! function key
if (i==27) goto 500 ! esc
GOTO 80 ! other key try again

400 IF (PO(1)/=PI(1)) THEN ! mouse moved
DE=DBLE(PO(1)-PI(1))*x2Efact
xin=xin+DE ! new coord
ENDIF
IF (PO(2)/=PI(2)) THEN ! mose moved
DN=DBLE(PO(2)-PI(2))*y2Nfact
yin=yin-DN ! new coord
ENDIF

500 call DebugLocation ('Out')
RETURN
END subroutine

[davidgraham]

Steve,
I'm not making any progress on sorting out this problem.
I'm wondering if I can send you the project? At present I am trying to strip out code as it is a large project.
Thanks,
David

[Steven_L_Intel1]

You can send me the project through Intel Premier Support. However, if there's no evidence of compiler or Intel library failure, I will only take a cursory glance at it to see if I spot anything obvious. I won't go into detailed debugging of Windows event handling.

[davidgraham]

I have been trying to cut my program to a size that I can send.
I have tried it on two more Windows 7 computers, it works on one but not on another.
Searching on the internet for "Windows 7 not responding" it looks as if the problem is caused by conflicts with other software.
Therefore it looks as if the problem may not be in the IVF.
Any suggestions on how I can track down this conflict.
Thanks

[IanH]

I'd consider connecting (attaching) to the hung process using a debugger (like the one supplied with Visual Studio) and finding out the routine or API call that the program is stuck on.

[dannycat]

Hi Ian,

Try adding a default message handler to your case list. I haveexperienced several problems with message loops that do not have a default message handler onmore recentoperating systems. The problem does not always occur but depends on OS PC, system achitecture.
Steve

[anthonyrichards]

I agree, try using

CASE DEFAULT
iret=DefWindowProc(hwndmain,msg%message,msg%wparam,msg%lparam)

to process those mouse messages that your code does not specifically handle and see what happens.

[IanH]

Note that the posted code is using PeekMessage with a filter range, so this isn't necessarily the characteristic Windows message handling loop. I'm out of touch with Win32 stuff these days - but this makes me suspicious.

Without knowing the rest of the application its a bit hard to comment further, but if you normally want to track mouse movement in an application you just process the WM_MOUSEMOVE message in your main message handling procedure (which must have the default message processing that's been mentioned, or your windows will be very sick). Similarly, if you want to wait on a mouse button click then set a global flag to indicate that your application is in a waiting-for-a-click-mode, and then wait for the appropriate button click message, while still processing all other messages appropriately. Often tracking of mouse movement starts in response to a mouse button down event, at which time the application captures the mouse so it continues receiving messages when the pointer wanders outside the window boundary.

[davidgraham]

Thanks for the suggestions. I will try this as soon as I can get my program to run. At present I can't get the menu etc to work (see my other post).
Thanks

[davidgraham]

I'm back to to this problem.
I added the suggested code (see below) and it made no difference - I get the message 'program not responding'.

CASE DEFAULT
iret=DefWindowProc(hwndmain,msg%message,msg%wparam,msg%lparam)

I have found that it doesn't work on Windows 7 if the code is in CVF or IVF.
The program works when not in Windows 7.
Also it works in IVF on Windows 7 when I'm debugging but not when I run the executable.

There must be a conflict going on somewhere.

Do you have any suggestions on how to track this down?

[davidgraham]

I have reported this problem to Intel Premier Support as it is a 'showstopper'. I upgraded form CVF to IVF to track down & solve this problem.

[Steven_L_Intel1]

Unfortunately, David, this is not the sort of thing Premier Support handles. Your problem is with Windows message handling and no Intel-provided routines are being used.

[davidgraham]

Intel Support was able to point out a few minor programming errors but Steve says,

"Probably what one needs to do here is use the Microsoft tools for "spying on" the Windows messages that are generated and handled. Usually when there is a hang like this, there's some message not being properly handled. I am not an expert in this area, however."

He suggests that someone on the forum maybe able to help.

As I have said the program hangs when I run the exe file but it is OK in the development environment. I have created a cutdown version of the program and data and instructions on how to reproduce the problem.

I would be grateful for any advice.

Thanks, David

[Steven_L_Intel1]

More specifically, the hang occurs only when the program is run under the debugger. I could not get it to fail in Visual Studio with "Start without debugging".

[davidgraham]

Steve,
I'm sure it's the other way round.
When I do Debug|Start Debugging (the full green arrow) it runs OK.
When I do Debug|Start Without Debugging (the green outline arrow) it hangs.
Or if I run the executable in the debug directory (this is what I would issue) it hangs.
David

[Steven_L_Intel1]

For me, it was as I said. I don't doubt that you see it different.

[IanH]

I've had a quick look. I'm not on Windows 7 here, so I can't reproduce the crash, but some observations:

- This looping with PeekMessage is very atypical of a windows application, to the extent that I'm really not sure what to expect. I see PeekMessage being used in a range of other locations - these all scare me.

I just reiterate the point in my previous post about restructuring the program so that this mouse tracking is handled by the main applications's message loop. When the user clicks a button that requires a feature to be selected then set a variable to indicate that your application is in a 'selecting-object' state, and then use an if statement for the handling of WM_MOUSE* messages in your main window proc (MainWndProc in Grade.f90?) to implement displaying the special cursor, etc. If you absolutely must run a separate loop then make it a full blown Get/Translate/Dispatch message loop (this is what the system does for you when your application displays a modal message box).

Your current approach ties up a core just to track the mouse!

- The return type of PeekMessage (and other api's) is not of logical type - it is INTEGER(BOOL). Whether a non-zero result maps through to .TRUE. logical result depends on a range of things. If you want to continue using a logical type then add a conditional test to the expression that assigns the result of the api to the logical, eg:

lRet = PeekMessage(msg,hWndMain,WM_LBUTTONUP,WM_RBUTTONUP,PM_REMOVE) /= 0

- If PeekMessage returns with a message that isn't one of the ones that you subsequently handle then you remove it from the queue without processing it. I imagine that this could annoy the window manager in different ways on different versions of Windows, such that it might think your application had stopped working.

- (This is what I guess is the underlying problem...) If your thread's message queue was full of things other than mouse input messages (and WM_KEYDOWN) that had been directed at your main window, then no more input messages could be added to its queue. In that case it would be stuck in an infinite loop and stop responding.

Your thread's message queue receives messages for more than just your main window, mouse movement might ultimately generate messages outside of the range that you are filtering for plus there's a whole host of other sources of messages on your system,all of which would be OS version (and even installed utility) dependent.