Thanks. I don't get any assertions from the IDE nor is anything in the watch window. The symptoms are (1) the process being debugged does not continue [debugee thread state is Wait:WrLpcReply according to ProcessExplorer] and (2) the IDE becomes completely non-responsive including not repainting the screen or responding to any window messages.
Quite frankly, I'm at a loss. I've really got to see what the App is doing in a couple of spots and this is preventing me from doing so. The next thing I'm going to try is disabling VisualAssist [although a VA thread appears to still be running -- as are the MSVCRT+0x6073 and dm.dll+0x5ee6 threads]. Nope -- still locks up with VisualAssist disabled! Sigh. Looks like I'm going to have to debug this the old-fashioned way -- lots of 'printf's... Ciao, Dee -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jason Teagle Sent: Tuesday, March 30, 2004 5:11 PM To: [EMAIL PROTECTED] Subject: RE: [msvc] VC6 lockup during debugging > I've been gleefully (ok, not really, but...) debugging several apps I'm > working on for months without incident. Now suddenly today the IDE keeps > freezing when I continue after hitting a breakpoint. There have been no > framework crashes yesterday or today and the only thing that has been > installed ('bout forgot about this) was LookOut! insisting on > installing the > Hebrew language pack when it encountered an email in the OffTopic > list from > Roy Osherove. > > I *really* don't have the time to repave my box right now and nothing else > seems to be having problems except for the IDE. Any ideas anyone? Wild shot: I don't know about lockups, but I did have a situation once or twice where breaking at a breakpoint I had (deliberately) set caused the IDE to issue an ASSERT inexplicably. It took me a while to figure out, but it was because one of the expressions I had in the user watch window was something like m_aryStrLines.GetAt(n) - I was using it to see what CString was at a position in the CStringArray in a certain context elsewhere, but at this breakpoint the variable was now out of the intended context and so n was beyond the actual storage space allocated in the CStringArray (imagine that the same array name was available at both places, so the debugger would try to evaluate the expression). Thus, it was asserting when it tried to update the watched value from this expression, throwing me right off-course. The moral of what I'm trying to say, is, be sure none of your expressions in the user watch window is doing something dodgy. -- Jason Teagle [EMAIL PROTECTED] _______________________________________________ msvc mailing list [EMAIL PROTECTED] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
