Printable View
Hi all,
I am debugging a multithreaded application. Just added a breakpoint and want the application to stop there.
However, one problem:
It happens a lot that Visual Studio stops responding. Now I don't care that visual studio crashes, but my computer will not respond and I have to restart the pc.
This is not the first time it happens. It is driving me crazy for months, but now I have had enough of it.
Is this a known problem? I am using Visual Studio 6.
Thanks!
[ moved thread ]
Have you installed SP 6?
No, not yet. Will that help?
Couldn't tell for sure. But after all Service Packs are made to fix problems. Hopefully it will solve your problem too.Quote:
Originally Posted by Tischnoetentoet
well, installed it, and it is not crashing until now!
So I hope the problem is fixed! thanks for your help!
well, it might be just a coincidence but let us hope for the best. :)Quote:
Originally Posted by Tischnoetentoet
Just out of interest, are you running under Windows XP? I've had this problem when debugging multithreaded apps for the past few years. Even with the latest service pack it still happens - though not as frequently as before. However, if I debug my app under Win2k it doesn't happen at all (and never has done). Fortunately, I have a dual boot system so I just transfer to Win2K whenever it starts happening.
My problem could be slightly different from yours, though. When it happens to me, the computer appears to have crashed and is totally unresponsive. However, if I go away and come back 15 minutes later it's back working again - but very slow.
yes, that is exactly the problem I am experiencing!
But rebooting is faster than waiting 15 minutes, that's why I reboot. However, it is really strange. Music keeps playing, if I press the power button, everything works fast, but I cannot control any application.
I am running windows xp, and this is a really strange problem.
Do you happen to know what motherboard & processor your machine uses? I used to have a Gigabyte GA-7VAXP with an AMD Athlon processor and it happened constantly. Then, just after I installed all the latest service packs, the mobo blew up (just by a coincidence) and I had to buy myself a new one. This time, I ended up with an Asus mobo. The problem still happens under XP - but nowhere near as often. Unfortunately though, I can't tell whether it was the upgrades that helped or the fact that I installed a new motherboard.
If you can spare the disk space though, I'd definitely recommend that you create a separate boot partition and install Windows 2000. :thumb:
I have Asus A6000 series notebook. But, I experienced this problem on a Dell machine as well.
So, I don't think this has anything to do with the hardware, but I think it's a vs problem. No matter how fast the processor is (in my notebook, I have Intel Centrino 1.7 ghz, the Dll was 2,7 ghz, so pretty fast machines).
However, I have not encountered the problem anymore since the update, but I have not tested it more than 10 times now. So let's hope it stays this way.
On a side note... The symptom of "Computer not responding" and "Visual Studio 6.0" not responding is often also manifested because of problems with the NCB file.
So, a good thing to do would be to close the workspace and delete all temporary files - NCB (trouble maker), OPT, CLW, APS, etc and then re-open, re-build and re-debug.
A lot of freezes are fixed by trashing that seemingly corrupt NCB (which is a generated file).
You are right in that one Siddhartha, I sometimes rebuild everything, and then it works for a few times.
However, if you change some little code, it hangs again. I don't want to rebuild all everytime I change just some small piece of code.
A corrupt NCB can be deleted (re-build is not needed for this one) after closing the workspace.
In general, debugging multithreaded applications is not that simple. Besides that, actually single-stepping thread code often takes away from the natural behaviour (in terms of sequence of code executed across threads) of the application itself.
I often use LOG files that record variable names and states to keep myself from single-stepping multi-threaded code. That saves me a lot of time... Just a tip... ;)
I also lived with the described symptom on Windows XP for a few years now, every now and then searching for a solution. Did anybody already solved this issue?
Not me - it's still driving me crazy. Only ever happens with XP. :cry:
Well, it's a long time I have had these lock ups. This is what I did (will not assure it will work):
1) Install latest service pack
2) When debugging in multithreaded, be sure to Rebuild All every time.
If this is not working, let me know so I can stop rebuild all each time :)
1) I've currently got XP SP2 installed. I don't know if that's the latest one but it doesn't make any difference.Quote:
Originally Posted by Tischnoetentoet
2) I'll give that a try for a few weeks!!
Well, I'd rather restart when VS hangs than rebuild all every time, this would take less time in case of my project (legacy code bload) :(
Do you have any plugins in VS installed? I had relatively good experience with first deleting the *.ncb file and disabling Visual Assist - only one lockup in about 20 debug sessions now...
Personally, I don't have any plug-ins installed but now that I think of it, you're right. It would be quicker to re-boot than keeping doing multiple rebuilds.
One other thing... how many of us are using VC++ 6.0 / VC++ 7.0 etc? I'm on VC++ 6.0
Now you are talking about it. Back then, I used Visual Assist a lot. Now, I don't have it installed anymore (trial was over), and no crashes.
But, I am not sure if I can say Visual Assist was causing the problems.
I also still use VC++ 6.0. I never before saw a need to update, and I like the IDE (the Class Wizard, for example, is apparently not part of the newer IDEs).Quote:
Originally Posted by John E
But I'm start to tire of the non-compliant compiler, especially as I start to use more of Boost. So, I might be moving to VS 2005 <shudder>
Mike
I am also on VC++ 6.0 SP6.
Now that I disable VA every time before I debug, I experience much fewer lockups.
Another thing to be checked is what other programs are installed and running, for example, I have NAV installed here. The firewall does not seem to be an issue, since I once used ZA and switched to Sygate but still experience the same problems. Also, I did not realize a difference from the MSVC service packs.