System freezez while debugging

[Intel_C_Intel]

Good folks, all of you who have Win XP!

Please start a new workspace and a new QuickWin application, paste the following code as your source code, build the executable, and insert a breakpoint at line 17. Now begin running the program in debug mode by pushing F5. Repeat pushing F5 very quickly. This makes my system freeze in some minutes after less than 10 times pushing F5. This does not happen if I make a console application with the same code, not either with DLL application even if I USE DFWIN and MessageBox in the DLL. This is just a little example. I have many deeply nested programs in QiuckWin which makes the system freeze a long time and it is impossible to debug them. I didn?t have this problem when I had W2K.

Does this happen to you too?

I have Win XP /SP1 in a Compaq Evo W4000 with a 2 GHz P4 and 256 MB RAM and have updated drivers for mouse and graphics.

	Program FreezeTest

	Implicit None
	Integer I
	Real(8) X(10000), Y(10000)

	Write(*,*) ' *** Start!'

	X = Acos(-1D0)
	Y = Acos(-1D0)

	Do I = 2, 9999
	  X(I:9999) = X(I+1) * X(I-1)
	  Y(I:9999) = Y(I+1) * Y(I-1)
	  X(I:9999) = - Cos(Sqrt(X(I))) * Sqrt(Y(I))
	  Y(I:9999) = - Cos(Sqrt(Y(I))) * Sqrt(X(I-1)*X(I-1))
	  Write(*,*) ' *** I = ', I      ! Breakpoint here
	End Do

	Write(*,*) ' Finished!'

	End

Regards,
Sabalan.

[tmcole]

Sabalan,

I posted on this previously and Steve (I believe) said that it was a problem with a mouse driver. In my opinion, it is not a problem with the mouse driver but is definitely related to CVF and XP. Do you find that sometimes it hangs with a varying number of F5 keystrokes? CVF folks definitely need to explore this further.

Tom

[Steven_L_Intel1]

What version of CVF are you using?

I tried your program using 6.6B on one of my XP systems. I managed to get the F5 count up to 100 with no problems seen.

Steve

[Intel_C_Intel]

Steve, if you ask me, it is 6.6B and you know it: I am still waiting a reply to my support inquiry #CVF19180 last sent on Dec. 4, 2002. I asked for example which mouse you use, to try it. Please try to press F5 faster! Or please try to insert your own nested subroutine and function calls inside the DO, especially with nested subs and functions outside the source code (in libraries). Maybe you have more RAM than my 256 MB (if this amount is the problem)?

Tom, it is exactly as you explain. Sometimes it happens after 1 or 2 F5 and sometimes after several. I know that you and many others have posted this before. Many people are complaining of problem with QuckWin in Win XP. A similar problem with W2K could be solved by updating the MS IntelliMouse driver. But this did not help me (nor apparently you) in Win XP. Mouse function and Windows message handle are present even when you build a similar code as a DLL with USE DFWIN and having a MessageBox in the code. But the problem does not occur there.

The problem is that it does not happen the same way all the time and CVF-people seem not been succeeded in reproducing it. What we can do is to cross our fingers and hope that they will try and succeed to reproduce and resolve the problem. Amen!

[Steven_L_Intel1]

If the problem is happening only with QuickWin applications, that gives us something to go on. Some of the other reports have suggested console apps were also an issue.

We have already seen (and fixed in 6.6B) a case where the part of QuickWin that responds to key presses gets confused in XP because XP is servicing the interrupt faster than before. It could be something similar is at work here, but none of us have really fast machines with XP loaded (the fastest I have available is 1.2GHz), so this may be a factor.

We'll poke at this some more, but I can't make any promises.

Steve

[Steven_L_Intel1]

Well, as it happened, the fastest PC I had access to with Windows XP, my home system with an Athlon 1.2, died earlier this week (something on the motherboard, I think). So I took the opportunity to replace it with a new motherboard and a shiny Pentium 4 2.53GHz processor. So of course I had to try Sabalan's program again.

Nothing... I could hold down the F5 key so that it repeated as fast as possible, and the debugger responded just fine.

If we can manage to reproduce the problem here, we have a chance at figuring out what causes it. Otherwise ...

Steve

[Intel_C_Intel]

Sabalan,

I don't mean to sound facetious, but if repeatedly pressing F5 freezes your system and that is a problem for you...erm...stop doing it. It doesn't serve any purpose other than to freeze your machine.

I know a bug found is a bug worth reporting, but I wonder how many other applications would respond badly to repeated semi-random key presses.

Dan

[Intel_C_Intel]

Ha, ha, ha...! This was really a good one.
You know Dan, I am not just sitting and playing with F5 to make my system freeze, but I have problem with Dev.Studio when I debug my code and I tried to give a little example to reproduce the problem. The problem is that I have several Fortran QuickWin applications in which there are DO loops, inside loops there are several subroutine calls, which call another subroutines, which call IMSL or NAG routines, which use user-supplied functions and call another 43 nested subroutines and functions. I want to debug this code, I insert a breakpoint inside the DO, press F5 to start the debugger, stop at breakpoint, watch some variables, press F5 again to repeat the procedure and see how the value of the variable changes, watch the variable, press F5 again, and here you are: the system freezes and I have to wait in minutes to be able to do something. This makes debugging impossible.

But thanks anyway for making me laugh here in the darkness of the polar Sweden.

Sabalan.

[Intel_C_Intel]

Sabalan, my apologies, as I said I wasn't trying to be clever.

Actually, I've had something of a similar problems with debugging our non-quickwin application (on NT/2000, CVF versions prior to 6.6, I'm not sure if 6.6 displays similar behaviour). It wasn't F5, but did have a 'funny' time delay. We have certain functions that perform as hash key lookup in relatively small arrays (~ 4000 UDT elements). Often if you tried to F10 over the call it would take several seconds for functionality to return to the debugger. Curiously, if you CTRL+F10'd past the call, it would execute in a flash. Could be related...?

Have you tried repeatedly 'Running to cursor' (CTRL+F10) instead of breakpoint + F5? (you'd have to set an initial breakpoint before the loop).

Dan

[Intel_C_Intel]

Sabalan,

I had another thought. The default solution tolerances for some NAG routines are extraordinarily tight, we've had situations where users (or coders!) forgot to override the defaults. This caused the processing to disappear into NAG and never return, or return after a very long time. So you might want to check any NAG routines with 'optional' parameters or overriable solution tolerances.

Of course, I think such behaviour would be consistant and present in both debugging and release, and it seems like you don't have such consistency...? (especially if the test program above 'breaks', which doesn't call NAG)

[Intel_C_Intel]

Thank you for your suggestions, Dan. I tried Ctrl+F10 and it does not matter. The system freezes. I deactivated the processor-cache in the system BIOS to slow down the computer. The system freezes. And regarding NAG, you wrote yourself that I don't need it to reproduce the problem.

Sabalan.

[jorjani]

Hi there,

Well, I tried Sabalan's code on my computer and I also had the freezing problem as Sabalan described, HOWEVER, the freezing problem was much worse than I anticipated it to be.

Computer was unresponsive for several minutes. I had several programs open at the time and I lost control over all of them. The task bar also went bananas. It was as if programs could come and go as they wished (as indicated by random appearance and disappearance of their windows on the screen or their icons on the task bar).

After several minutes I managed to activate task manager (By CTRL+ALT+DEL) and shut down all programs. Even here I had a lot of troubles shutting down programs.


My computer has the following specifications:

Dell Latitude
Intel PIII 650 MHz
256 MB RAM
and CVF 6.6B

If I get some time around I may try this on my dual processor computer at my office to see if my Xeons behave differently!

Best regards ... Hossein

[Intel_C_Intel]

I have tested this same code on two other computers at my company: 1- An Intel CC82010A, P3 498 MHz, 128 MB RAM with WinXP Pro Ver. 2002 SP1, CVF 6.6B; 2- Another computer exactly like my own (see the beginning of this thread. - My Win XP is also Pro.). Both of them freeze after 3 mouse-clicks on the "Go" button (Task manager, if you succeed to start it, says: Program, i.e. my exe-file, not responding). For the first computer it took 20 minutes to be able to end the not-responding-program in the task manager, but 1 minute for the second one.

These, and Hossein's message, show that the processor speed is a secondary factor in this behaviour.

Steve, do you make a QuickWin workspace and project from scratch, and do you use the same compile and link switches as default ones in the Dev.Studio for CVF 6.6B which end-users have?

Sabalan.

[Steven_L_Intel1]

sabalan,

I followed your instructions exactly. But now you say you're clicking on the Go button rather than pressing F5?

Steve

[Intel_C_Intel]

Steve, it doesn't matter: F5, Ctrl+F10, clicking on the Go button, or whatever you do. The purpose is to debug the code and watch for example the variable I and see at which value of I you get the computer freeze. For me it happens with all of these.

Sabalan.

[Steven_L_Intel1]

Ah, ok. Well, it doesn't for me.

Try this - boot into Safe Mode (press F8 when the system first starts booting to get the menu) and do the experiment again. What happens?

Steve

[Intel_C_Intel]

Well, I rebooted with "Safe mode with network" (otherwise couldn't log on the computer) and tested the code. It DIDN'T freeze this time! What does this mean, Steve, and how can I solve the problem? It must be a common problem in our 3 computers and even Hossein's system.

Sabalan.

[Steven_L_Intel1]

Safe mode skips loading a lot of the optional drivers and applications. In particular, you get a generic VGA video driver instead of your regular driver, and perhaps a generic mouse and keyboard driver as well.

That it doesn't fail in Safe Mode suggests to me that the problem is caused by some driver or background application that is watching the keyboard or mouse. Figuring out which it is means a lot of trial-and-error - uninstall one driver, reboot, try the application, repeat as needed. It may not be a driver, it may be some background program that "hooks" into system calls.

What this DOES tell me is that it isn't a bug in CVF, since if it were, it would do the same thing in Safe Mode.

Steve

[Intel_C_Intel]

Eureka!
After a painful and time-wasting checking of all hardware and updating all drivers, I learned finally How to Perform a Clean Boot in Windows XP. Following those instructions step by step, I found at last the villain by name ctfmon.exe, a ?startup item? which runs in the background. It belongs to both Office XP and WinXP.

?Ctfmon.exe monitors the active windows and provides text input service support for speech recognition, handwriting recognition, keyboard, translation, and other alternative user input technologies?. ?... It starts the Language Bar component (in the Systray) and remains running in the background even after you quit an Office XP program. It also starts each time Windows is started and remains in the background, regardless of whether an Office XP program is started. Ctfmon.exe is designed to continue to run in the background during Windows sessions after the Office XP Alternative User Input components are installed?.

Do I need it? NO!

Is there an easy way to get rid of it? Are you crazy?! MS can not make anything easy for you! You have to follow the instructions given in OFFXP: What Is CTFMON and What Does It DO?, but it is not enough! Don?t forget to read Programs May Start, Quit, Lose, and Gain Focus Randomly(!!!) and carry out the instructions given there too. You can find millions of complains about CTFMON in the Internet.

Now I can debug my QuickWin applications smoothly. But, Steve, maybe it is worth to take a look and see why just QuickWin applications and just when debugging conflict with CTFMON, because there can not be any doubt that MS is going to carry on CFTMON-ing.

Sabalan.

[Steven_L_Intel1]

I had never heard of CFTMON before (and don't have it loaded on my systems.) Thank you very much for tracking this down!

It sounds as if CFTMON has some bugs that cause it to interact poorly with Windows applications. Remember that QuickWin is really a Windows GUI with keystroke processing in a message loop thread. If CFTMON corrupts the message queue, or otherwise "plays poorly" with other users of Windows messages, all heck can break loose.

We'll keep note of this in case we get other reports of this problem.

Steve

[Intel_C_Intel]

Steve, I think it should be possible to reproduce the problem in your XP system easily instead of waiting for further reports about the problem. All those who use more than one language in their systems, and have a language bar on the task bar, are going to have this problem. It is worth a try, it takes only a few minutes and it is not that dangerous, I promise! It would be enough to turn on "text services". To do this, two methods are given in the last article which I addressed in my last message. I cite one of them. Do this:

A- "1- Click Start, and then click Control Panel.
2- Click Date, Time, Language, and Regional Options.
3- Click Regional and Language Options.
4- Click the Language tab, and then click Details in the Text services and input languages box.
5- Click Language Bar in the Preferences box.
6- To turn on text services, click to clear the Turn off advanced text services check box. To turn off text services, click to select the Turn off advanced text services check box."

This is going to ask you to restart the computer. After that you are probably going to see the language bar on the task bar, to the right (if you had not locked the task bar). Now you can start Task Manager and check if CTFMON (and not CFTMON) is running.

B- Test my example given in the beginning of this thread.

C- Follow 6 steps given in "A" to turn off text services.

D- Try to make MS accept that this is a bug in their product!

Sabalan.