Visual Basic Debugger Crash
- I have just recently installed Visual Studio 2005 and in my GUI Design class we have opted to use Visual Basic.
The problem I am having is that whenever I try to use the debugger by setting a breakpoint, everything goes well until I actually reach the breakpoint.
When my program reaches the breakpoint, everything freezes up. I am unable to force quit the program or Visual Studio, or alt-tab to any other applications. The only thing I am ever able to do is bring up the task manager with ctrl-alt-del, but I am unable to kill processes or anything from the window, as it too freezes when I click on the window with the mouse.
This is on a fresh install of Visual Studio 2005 on a fresh install of Windows XP Professional SP2. I have all the updates that were available, using .NET 2.0 (I do not have 1.1 installed).
Is that the reason for these crashes, or is it something else?
Thanks in advance.
Answers
- This is the same issue that I spoke about a while ago. I would hope that all of you can help force MS to solve this issue. It exists in Windows 2000, XP, and apparently Vista. It occurs with Visual Studio 6, 2003, and 2005, and I'm sure all other recent versions. It is most often caused by msctf.dll, but other DLLs can cause it too. It is the global semaphore problem. I had a case opened with MS, but the final response was that they will not fix it, especially b/c I could disable Advanced Text Services in XP. Since you can't disable it in Vista I would hope that they will finally address this issue.
Report this issue to MS, and make some noise about it.
Nachum Kanovsky
All Replies
- Are you mulit-threading? Does this happen on any break point or a particular line of code?
- As far as I can tell, this happens on every breakpoint, whenever it is reached during run-time. I created an empty project and set a message box to load when the main form loaded, then set a break point just before that.
I never saw the window load and my system all but locked up. I can still hear sounds (if someone sends me an instant message) and any music streams continue (for example, a streaming broadcast won't just 'kill' when the system seems to freeze; it continues as it would under normal conditions).
I will try to do a 'repair' on Visual Studio later, but I can't think of any other reason. The C++ Debugger works just fine, though I have no idea if they are linked/related in any way at all. Are you trying to download symbols from a symbols server/network share? I've seen the UI temporarily lock up while trying to download symbols until you get a network timeout. I haven't seen the debugger crash due to this, though - it usually comes back to life after a while...
Best regards,
Johan StenbergI have seen problems with Edit-and-continue, but not quite what you are reporting. You may want to look into the QFE that came out a while ago as it may help your prolems. See http://www.panopticoncentral.net/archive/2006/08/03/13539.aspx for details about the QFE.
Jim Wooley
http://devauthority.com/blogs/jwooley- No, I wasn't trying to download symbols from a server/network share.
I waited for over an hour once, and my system was still locked up, so I'm pretty sure it would have timed out by then if it was trying to do anything with the network.
Anyway: I popped in my disks and did a repair to VS 2005, which fixed it straight away.
Don't know what the issue could have been, as I hadn't even changed any settings and I kept the defaults for the install, both times. Seems to have mysteriously fixed itself, which I don't particularly mind :).
Thanks for all the suggestions. - No, I wasn't trying to download any symbols from a symbols server/network share.
My IDE would lock up and cause most everything in Windows to lock up, for over an hour. My computer would not leave this state, no matter how long I had waited, until I simply rebooted.
Anyway, as for the problem, it was fixed by doing a repair with the install disks. I didn't change any settings or choose anything other than the defaults and it miraculously fixed itself. I can't say that I'm upset with that, I just wish I knew what had caused it the first time.
Thanks for all the suggestions. - No, I wasn't trying to download any symbols from a symbols server/network share.
My IDE would lock up and cause most everything in Windows to lock up, for over an hour. My computer would not leave this state, no matter how long I had waited, until I simply rebooted.
Anyway, as for the problem, it was fixed by doing a repair with the install disks. I didn't change any settings or choose anything other than the defaults and it miraculously fixed itself. I can't say that I'm upset with that, I just wish I knew what had caused it the first time.
Thanks for all the suggestions. - Please post whether this helps you, and read on for a workaround to the issue.
I would like to pressure microsoft to fix this issue, so i have been searching out people who have been suffering from this bug to update you on what the issue appears to be. I am assuming that your issue is the same as what I've run into, and that this explanation applies. The progress on Microsoft's side seems to be coming to a halt even though this plagues Windows XP with Visual Studio NET 2005 and earlier. Let me know if this helps you.
I am happy to finally be able to give someone some information on this issue. I have opened a case with Microsoft. The problem is caused by DLLs that use global semaphores, and attach to all windows. What happens is that Visual Studio also uses global breakpoints and when it stops one window, then the other windows are all stuck due to the DLL that is still trying to get that global semaphore.
Example, Microsoft's language bar (msctf.dll) attaches to every open window, and has one global semaphore for all of them. Typically Window A will get the semaphore, and then release it, so that Window B can get it and so on. If Window A gets a breakpoint between the time when it got the semaphore and before it released it, then all other windows will be stuck waiting for it. Thus the Window's freeze. I have found that msctf.dll is the worst offender. Other offender's were Synaptics dll, but with their dll it occurred once in 30 or so attempts of my sample program, and with msctf.dll, it occurred almost every time.
To disable msctf.dll you will also be disabling the language bar. Go to start -> settings -> control panel -> regional and language options. Go to Languages -> Details -> Advanced. Place a check in Turn off advanced text services.
I hope this helps you. Microsoft is currently reproducing the problem in America, as their service people in Israel have already managed to reproduce it. I do hope there is some progress in the near future. This is apparently considered a bug for the language team, and not for the Visual Studio team. If you are writing DLLs that attach to all windows, DON'T use global semaphores!!!
The problem is the dlls that are loaded and attached to every window. For example the msctf.dll (language bar dll) is loaded with each window that is created. Since that dll uses a global semaphore it causes all windows to freeze (waiting on the semaphore) when one of the windows is stopped due to the visual studio breakpoint when it holds that semaphore. If you have the language bar, then it will most definitely help if you turn it off in the way that i explained as the language bar dll is a bad offender of the "don't use global semaphore" rule. You can also tell what other dlls are being loaded and attached to each window by looking at the visual studio output when you close your program.
It should look something like this:
Loaded 'ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic information found.
... with many more loads
I used to have the line with msctf.dll until i disabled advanced text services, that was the dll that caused the most problems.
Nachum Kanovsky - I've had the same problem as described by the OP. I'm running XP SP2 and whenever I set a breakpoint after I spawn a new thread (for D3D rendering), it will always freeze up all of windows. Is there something special I have to do when setting breakpoints in a multi-threaded application? If I set the breakpoint before the D3D rendering thread, it seems to work fine.
- There is a Beta version of VS2005 SP1. http://www.microsoft.com/downloads/details.aspx?FamilyID=8D702463-674B-4978-9E22-C989130F6553&displaylang=en
- Thanks for that link. I've downloaded and installed it, however, it hasn't remedied the issue.
- has anyone tried to do what i recommended a few messages back? the problem is probably the global semaphores of different windows dlls. disable advanced text services (the worst offender for this problem that i know of), and see if that helps. already one person who has used this as a temporary workaround for now besides myself. microsoft i believe is working to solve the issue, but if i can get confirmation that this has helped any of you too it would help to add to the pressure on microsoft to fix it.
- Veit,
There's nothing special you have to do when setting breakpoints in a multi-threaded application. However, there are often issues that arise when debugging managed multi-threaded applications that may or may not be related to what you're experiencing.
Please take a look through the Debugger FAQ at http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=56&SiteID=1. In particular, please make sure you tell us as much about your debugee, platform and scenario as possible.
Also, the original poster indicated that repairing the VS install alleviated the problem. Have you tried that? It would be good if we could get to the bottom of the problem before doing so, but if you already have, that would be interesting to know.
- I moved this thread from the Visual Basic forum to the Visual Studio Debugger forum.
Nachum Kanovsky
I have a similar problem with advanced text services. This problem appeared after some unknown updates around Oct 2006. My program crashes on this line
ddrval = lpDD->SetCooperativeLevel(master, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN |DDSCL_ALLOWREBOOT);
whenever it runs for the first time after you logged in the machine. Successive runs are fine.
Turning off the Advanced text scripting solved this problem. I still don't know how these things are linked?
I now have this exact issue on Windows Vista (not beta).
And the sad part, you cant disable text services on vista as I beleive its a core part.
Something to add, it must be a configuration/update problem because if i login as a different user, and run the same steps, the vista ui does not freeze. I now have to debug under a different account because if i do it under my normal one, the problem occurs.
I have also seen the problem during normal windows use, but more rare (the vstudio breackpoint + gui freeze is reproducible every time)
I find it terrible that such a blatant bug is not addressed.
Nicolas,
I'd like to get to the bottom of what you're seeing. I know you said you were
, but I want to verify you are seeing exactly what the original poster experienced on Vista? Here's the meat of the original post:
"The problem I am having is that whenever I try to use the debugger by setting a breakpoint, everything goes well until I actually reach the breakpoint.
When my program reaches the breakpoint, everything freezes up. I am unable to force quit the program or Visual Studio, or alt-tab to any other applications. The only thing I am ever able to do is bring up the task manager with ctrl-alt-del, but I am unable to kill processes or anything from the window, as it too freezes when I click on the window with the mouse."In particular I want to verify that the hang just isn't of Visual Studio itself, but of the entire OS. What version of Vista are you running? Was it a upgrade or clean install?
Jim
Correct.
When the debugger reaches the breakpoint the entire OS seems to hang, but doesnt really.
I cant change windows, i cant open start menu, i can sometimes (if im lucky) do ctrl+alt+del and either reboot, or force a logout. Loading the task manager is of no use, as it will act frozen. I know the computer is still running because MSN Messenger still pops-up the notices, and task man (running before debug) doesnt show any excessive cpu and continually updates the task list.
Im running Windows Vista Ultimate. Was originally pre-loaded on the computer, but I had to re-install clean.
Ive tried to close as many tasks as possible and re-running the scenario, but the problem persists.
Visual Studio 2005 SP1 + the vista patch.
My project is a Visual Basic project.
If I login under a different account (newly created to test with) and run the debugger when it hits a breakpoint everything is as it should.
I dont recall installing any specific updates before this problem occured, but vista is set to update automaitcally.
(and even if it was an update, the other user account would exhibit the same problem)
I have the language bar set to not display (but theres no way to fully disable it)
This problem is moreso a windows problem, not so much a Visual Studio problem it seems.
I have seen this same problem two times when running other programs. And some apps load slower than before.
Any tests you want me to perform ?
I would guess this is the global semaphore problem that is talked about here
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=916709&SiteID=1
and that nkanovsky talked about previously in this thread.
So if that is the case, is there some application or driver which runs under one user account but not another?
Not as easy to disable/find the problem program.
Ive narrowed it down to an instance of svchost.
Is there any procedure/tool for seing what mutexes/semaphores are being used/held in the global scope of windows ?
Using Process Explorer and some digging around I found the faulty mutex and process.
Use the find function to search for 'mutex' then look for the mutex that is most commonly used (and hooked into by almost all apps)
Yes it is the language services subsystem.
The problem mutex is
\Sessions\1\BaseNamedObjects\MSCTF.Asm.MutexDefaultS-1-5-21-1586721351-2053333904-3076651018-1000
Which is part of msctf.dll, the version on the dll is 6.00.6000.16386
The process that seems to be causing the problem is explorer.exe (the shell).
When I kill explorer, while vstudio is running, the UI does not freeze upon reaching a breackpoint.
I killed all proccesses that where using that mutex, except for explorer, and when hitting the breackpoint the UI freezes still. So it seems to do with how explorer.exe is dealing with the language service.
The only apps left using the mutex are winlogon.exe and devenv.exe (vstudio) and the app being debugged.
Several other proccesses are hooked into the msctf.dll, but they dont seem to be making use of the mutex (proccess explorer does not list the mutex for them)
Now would any MS guys care to take a stab at this ?
And I have yet to find a way to disable the advanced text services in vista, and removing the msctf.dll is not an option, as it makes vista fail (its core to winlogon)
- This is the same issue that I spoke about a while ago. I would hope that all of you can help force MS to solve this issue. It exists in Windows 2000, XP, and apparently Vista. It occurs with Visual Studio 6, 2003, and 2005, and I'm sure all other recent versions. It is most often caused by msctf.dll, but other DLLs can cause it too. It is the global semaphore problem. I had a case opened with MS, but the final response was that they will not fix it, especially b/c I could disable Advanced Text Services in XP. Since you can't disable it in Vista I would hope that they will finally address this issue.
Report this issue to MS, and make some noise about it.
Nachum Kanovsky Yes. Thanks to your post I was able to at least understand the problem, and start to diagnose it. but sadly, the text services cannot be disabled on Vista.
Im certain it is a configuration/setting somewhere that is causing this problem.
As I noted earlier, under a different user account this problem is not exhibited. Under my main account, I have tried closing down virtually every program, service, and driver I can imagine, but as long as explorer.exe is running, the problem persists.
If they know what the problem is, advanced text services and the semaphore, then what is so hard about fixing that stupid bug. Grrr.
On the bright side, when I want to debug apps now, i just kill explorer and go on my merry way.
I would like to enter a bug against Windows to help investigate this issue. Would somebody on this thread please post the following information?
- What version of Vista demostrates the problem (I'm assuming the latest RTM version)
- Language settings for the OS
- What version of Visual Studio (Help->About)
- A simple set of repro steps involving debugging using Visual Studio, preferably one that involves creating a default project such as a VB Winform or VC++ Win32 Windows application.
I expect that the result of the repro steps will cause Windows to hang as described in the prior posts on this topic.
You can also contact me directly at Jim.Griesmer(at)microsoft.com, if you'd like.
- This is the MS support case # that I received 10 months ago : SRQ060510601488
Hope this helps,
Nachum Kanovsky I'll see. However, the windows team is asking us to open a new bug, since the original cause was indeed addressed. They don't deny there could be other places that need to be addressed. Therefore, they want a new bug entered.
A scenario involving Vista would be ideal.
- Thats fine, but I'm sure that the original cause wasn't addressed, as I was the person who opened the bug, and I was told in the end to turn off advanced text services as a workaround to the problem. How did they say that they addressed the original problem?
In the end they told me that the bug wasn't in Visual Studio, but rather in the way msctf.dll uses global semaphores, so perhaps the bug shouldn't be submitted to the Visual Studio team, but rather to the Advanced Text Services team.
nachum - Thank you guys so much! I have had this problem for at least a year with Visual Studio 6 on XP SP2. I do not see it on Windows 2000 with VC6 or with VS2003 or VS2005. Disabling the advanced language support seems to help, but it did still freeze VC6, just not the whole explorer.
Brian
