there is only one taskhost.exe (task scheduler host), but several svchost.exe (the service host - as in other Windows OS, too).
The following is strange for me:If I don't kill the taskhost, the QuickWin app freezes (as described previously). If I kill the taskhost, then the QuinWin app doesn't freeze. Some time later (minutes to hours), the taskhost is restarted by the OS. But then the QuickWin app doesn't freeze anymore ??
I guess there is some DLL that taskhost is "hosting" that is triggering the freeze. If others could do this same experiment and post the results, we might be able to identify the common element.
I'm having this same problem of freezing when I call a dialog box for file save. I'm wondering if anything has come of a final resolution to this problem? I ask because May 4th is the last time there was any discussion.
No resolution yet - we still cannot reproduce the problem here. If you could provide the information requested from Process Explorer, that would be helpful.
I was able to repeat the problem at will. If I kill taskhost, my program runs without freezing. If taskhost is running, my program freezes every time. I ran progress explorer to see what was using my CPU time. I was surprised that it wasn't taskhost. There are two threads running for my program that use a total of50% of the CPU time. When I click on one of the threads it is going from a status of wruserrequest to running to ready. It continually repeats that cycle. The other thread using CPU time is doing the exact same thing.
I did not have time last night to capture the data you requested. I will try to do that tonight. Hopefully, some of this information is helpful. Let me know if there is something more specific you would like to see from progress explorer. I will capture the information you requested in an earlier post.
If you boot into Safe Mode and run your program, does the same thing happen?
My program runs in Safe Mode, but then Taskhost isn't running.
I took some time running it with Progress Explorer running to produce screen shots I hope will be helpful. This problem exist, for me, in MS 7 32 & 64bit Ultimate. I checked to make sure all updates are installed. This program is compiled in MS XP Pro 64bit as a 32bit app. I used MS Visual .NET 2008 with Intel Fortran Ver 11.1. I can run this app in Vista 32 & 64bit OS. The above is background info.
Below is an attached file in MS Word 2003. Hope the screen captures help.
Thanks. I'll pass this on to the library developers. That it doesn't happen in Safe Mode, though, makes me wonder if there's some background task that is interfering, Would you be willing to try selectively disabling startup tasks in msconfig.exe and see if one of them is the culprit?
That is a good point. I'll try to spend some time on it Sunday. I'll post the results.
have you and your team made any progress? Could you please give us an update?
I wish I had better news - we are still unable to reproduce this problem in-house. We are still trying.
The internal issue ID is DPD200149113.
I am also having this problem and have found if I suspend "MSCTF.dll!DiiGetClassOdject+0xc8c" that is listed as a thread running under "taskhost.exe" my programs do not hang. My programs are slow to respond while it is suspended, but they do not crash.
I have attached a screen shot of taskhost properties showing this thread.
Very interesting. MSCTF.DLL is related to the known troublemaker CTFMON.EXE process. It's part of MS Office and handles "Alternative User Input Text Processor" and the Microsoft Office Language Bar. See if the removal instructions in http://support.microsoft.com/kb/282599 make the problem go away for you.
I am running Office 2010 Pro 32-bit on Windows 7 Pro 64-bit and have already searched for a way to disable Windows Test Services, but everything that I found said that you cannot disable it on Windows 7.
Do you think that article is still appropriate for me? I don't want to cause more problems while trying to fix this one.
Try the steps shown here - in particular, removing all keyboard layouts other than the one you use. On my Win7 system, I get no language bar because I have only one keyboard defined.
Under Change KeyboardsI had two listed. The standard US keyboard "EN English (United States) - Keyboard - US " and under "Other - Ink Correction (64bit only)". I removed the "Ink Correction (64bit only)" entry and rebooted. Now MSCTF.DLL is no longer listed as a thread under TASKHOST and my programs no longer hang or crash.
And with this clue, I can reproduce the hang by adding a keyboard. Thanks! I have let the developers know about this.
As described in earlier posts, I have this problem with W7 32 bit too. I deleted the additional keyboards, but this does not work. I habe to kill taskhost.exe, then all works. So Steve, is there any solution and when will it be available?
We have not yet figured out what is going wrong. Yours is the first report of a problem on 32-bit Windows and the first to say that the problem remains after deleting keyboards. We are actively investigating the problem, but it is VERY difficult to diagnose given all the things that are interacting, some not under our control.
I have a user in Greece that has the same problem. He has a dual boot x64 that he can start in both 64 and 32 bit and both has the same issue. I explained the issue about the multiple keyboards to him, he misunderstood (him being Greek and me being Afrikaans) and disconnected the keyboard completely and used the screen keyboard utility that is mouse operated. And now the software runs without freezing. It is a USB keyboard. Next he wants to try the PS2 keyboard but could not get it working - he is still investigating.
Perhaps we should rejoice that it did not occur to him to use a hammer to 'delete' the keyboard! :)
After many hours of reading these posts and debugging QuickWin and Windows 7, I'm replying to the posts to see if anything new has changed in this area. We (Fortran RTL engineers) have been trying to track down exactly what the Fortran RTL and/or QuickWin are doing that seems to send Windows 7, and more specifically, taskhost.exe or the thread MSCTF.dll!DllGetClassObject, over the edge and lose the focus on the QuickWin window.
While we can pinpoint the Windows API call that results in the hang, it's not clear why that is happening, and why anything external (running other MS applications, ensuring only one keyboard is configured) would cause this API call to result in what looks like the QuickWin window losing its focus. The call we see that never returns is to WaitForSingleObject(HANDLE, INFINITE).
The investigation continues here. Any new developments or discoveries are appreciated.
Bob, thanks for the update. If you have any testing you need done or test programs you want to run, I have a user in Finland and one in Greece that are prepared to test.
Some more info:
On a 32bit Win7 if I start the application with a dialog it never returns focus to the QWin. If I go straigth into the QWin without using the intro dialog it works fine.
I also tested with a dedicated callback for the OK button rather than the default one but the problem persists.
I have seen this problem on 3 different W7 x64 machines, one of which has 'self healed' for no obvious reason. In all cases killing taskhost.exe solves issue but this is not news to anybody following this topic.
Out of interest if WaitForSingleObject(HANDLE, INFINITE) is replaced with WaitForMultipleObjects does the problem go away by some other input triggering the focus returning? Some workaround would be very helpful.
Andrew, et al,
I have what looks to be a fix for this problem. (and there was much rejoicing). We want to try a few more things today and early next week, but hope to post the change here in the form of the library iflogm.lib. When I do that I'll post the x86 and x64 versions.
Unfortunately, the change cannot be made available in 11.1. We hope to get it to the second update for 12.0
Never surrender, never give up.
I have a problem that might be related, but not sure:I am using a Quickwin program under Windows7, 64bit. The program reads several data sets and plots them to the screen, allowing to modifiy them and then to go on with another data set. In addition, it opens a file at the beginning and writes some control info. Everything works fine for the first data set.
However, when I want to go on, the program freezes when it should close the child window (OPEN(unit, FILE='USER'...). I avoided closing this window, but then the program freezes absolutely randomly, sometimes when trying to write into the output file, sometimes when I want to write a message into window#0. I have change the interactive input to pass through a dialog box instead of window#0, the same: Sometimes it freezes near the first call, sometimes at the second - absolutely random. Up to now, I didn't get it through to the dialog box in the debugger, it freezes before if I make big steps, if I go step by step, it usually gets through to the dialogu box but freezes anywhere.
Has anybody experienced this problem?I tried all the above suggestions (one single keyboard, Taskhost is not running, I closed all Office programs and VS etc. etc.)
Neels and anyone else experiencing this QuickWin freeze problem,
I have a solution that looks good from this side, but I would like to have it tested using real applications in the field that have experienced this problem. I've posted two attachments for the iflogm.lib library, one for x86 and one for x64. They should be attached here as zip files.
I will watch this forum for feedback on these changes. We want to make this available in the next 12.0 update, so the sooner we can get some real world testing on this the better.
Thanks for all of your input on this problem.
Bob,I have only tested it on WinXP 32bit and it now freezes where before it always ran. Neels
Hmmm, not what I wanted to read here. Let me push on the XP thing here a bit more, although we did run qwin tests there. I will do some more testing and post again here later today.
Does it freeze in the same way that we see with Windows 7? If so, that is very odd.
If you can, please try it on Windows 7.
These libraries, btw, were built for 11.1, which I assume is what you are running.
Thanks for the road test......
I've tested the x86 and x64 libraries that are posted here with XP and Windows 7, with the test application, and the test completes without hanging.
I will continue to do testing here (there are multiple reproducers available).
If you could, could you post the program that you are testing, along with any instructions needed to build and run it?
No, I am running Composer XE 2011 Update 1.
Will test it with 11.1.
I will let you know.
I does the same with 11.1.
I can zip and send you the complete project if you let me know where to. (vannik07 at gmail dot com)
Well, you should be able to post it right here, seems to me. I'm hoping that it's not a huge project. As always, small reproducers are the best reproducers. :-)
See if you can upload it from the new post page. There is an "Add Files" button to the right of the word "Description".
It is part of a software suit that I sell so I would not like to post it here.
I am an engineer that does a bit of programming, not a programmer that does .......
Do a Build > Clean of the solution, ZIP it and send it to me at steve dot lionel at intel dot com - I'll make sure Bob gets it. Make sure you also include instructions on how to run the program and reproduce the error.
Could you let me know if this application hangs on Windows 7, both before and after the fix that I posted?
Bob,Will do. I have access to a Win7 machine tomorrow.Neels
For the specific application of mine that you do have, compiling it with 11.1.067 with the old lib:
It runs fine on both WinXP and Win7 - 32bit.
It hangs in both using the new lib.
I am waiting to hear from the user in Finland what happens with the Win7 - 64bit version.
The new lib does exactly the same and freezes on the Win7 64bit version.
Sigh, yes, we are seeing the same thing here. I'm having some trouble building a debuggable runtime to debug the problem, but I'm working on it.
The people I'm working w/ at Microsoft believe this is "bad timing", and that changes in Windows 7 coupled with the way that QuickWin is handling multiple thread input is aggravating that timing. It's interesting that the change that was made has had an impact to the application running on XP also.
I will post progress as it arrives. Thanks for working with us on this.
Could you help me out with something in your application? There is a call to waitonmouseevent() in Post2T.f90, line 132. This is where the program basically waits on things to happen from various pulldown menus and dialog boxes. My problem is that I can't find this function and I'd like to step into it.
I'm sure that I'm missing something obvious here, but I don't know what that is.
Can you help me with that?
Never-mind. Found it in QuickWin.
I'm back working on this problem and now have your application running successfully on both x86 and x64, on XP and Windows 7. I've been working with Microsoft on this (who have been very helpful) and it involves a timing issue with the MS Window Manager and the QuickWin implementation. It is not an exact science, unfortunately.
I've attached a new version of ifqwin.lib for both x86 and x64. Please restore your original iflogm.lib, as that change has been done away with. They were built for use with Composer XE 2011 Update 1.
I apologize for using you as a test case, but, well, you're so good at it. :-)
Let me know what you see there. If you have other QuickWin applications trying it with them would be appreciated.
Ok, I tested the x86 version on 4 aplications on WinXP x86 with no problems. I have sent a x86 version for testing on the problematic Win7 x64 machine in Finland and will test the Win7 x86 tomorrow.
My name is Bob Mance and I've been working on this Windows 7, QuickWin problem, and have posted a solution near the end of this thread. Please pick up the ifqwin.lib that is posted there.
Also, I've tried to duplicate the hang from what you posted earlier with Steve, but the program is failing due to not finding a resource. Could you do me a favor and post the application components after making sure that it builds and works OK on XP?
I have other reproducers that are working, and I have the feeling that maybe I'm missing a piece of yours. At least I hope that is the problem. The place it is failing is the call to dlginit in the in_out subroutine.
My name is Bob Mance and I've been working on this problem with Microsoft. I've posted a solution that works for yours, and several other reproducers posted here. You can pick up a new ifqwin.lib file from that post, #94 I believe. The library was built for a 12.0/12.1 release and can be used on XP or Windows 7.
I know that many are running on 11.1, and I will try to post 11.1 versions of the library as well.
Let me know if you try it and what you see. I have your application running here fine.
The x86 version is running fine on Win7 x86 as well.
thanks a lot for the libs. I recompiled our application with them using the 12.1 version of the compiler. They are working great here on Win 7 64 bit (for both, 32 bit and 64 bit applications). The lost of input focus is disappeared, no freeze anymore!
Thank you very much, again.