Debug version crashes the second time
-
Hi all, I have a weird problem. When I debug my application in Visual Studio the first time, everything works fine. When I press F5 again my application has an access violation when I move the mouse over the commandbar. Sometimes after stopping the debug, the visual studio crashes also. I use Visual Studio 6, WTL 3.1 and running on Windows98. Franky
-
Hi all, I have a weird problem. When I debug my application in Visual Studio the first time, everything works fine. When I press F5 again my application has an access violation when I move the mouse over the commandbar. Sometimes after stopping the debug, the visual studio crashes also. I use Visual Studio 6, WTL 3.1 and running on Windows98. Franky
I've seen this, I think, or something like it on win98. Sometimes something seems to go squirrely with the common control dll (?) during a VC session and as soon as the mouse moves over a toolbar button in my app it faults. I think I've seen it when I switch to a release build. Once this occurs, toolbars in other apps can start to exhibit the same behavior - which makes it hard to even use explorer. Rebooting usually straightens things out. My 98 system is a very 'feature packed' mixture of DLL pudding at this point, still proudly displaying april 98 on bootup. I think it was upgraded from the beta. Plus, it supports two monitors, each with its own driver, which might have an impact. The prime suspect in my case might be a rollback from IE 5.0 that occurred sometime back, and left IE a bit crippled - thats why I suspect some sort of comctl32 messup - which certainly could impact on toolbar functionality, styles etc - though I don't know if I've seen this happen for the command bar. Does this always occur? If you fire up your machine and don't open IE, going straight to VC instead, does that make any difference?
-
I've seen this, I think, or something like it on win98. Sometimes something seems to go squirrely with the common control dll (?) during a VC session and as soon as the mouse moves over a toolbar button in my app it faults. I think I've seen it when I switch to a release build. Once this occurs, toolbars in other apps can start to exhibit the same behavior - which makes it hard to even use explorer. Rebooting usually straightens things out. My 98 system is a very 'feature packed' mixture of DLL pudding at this point, still proudly displaying april 98 on bootup. I think it was upgraded from the beta. Plus, it supports two monitors, each with its own driver, which might have an impact. The prime suspect in my case might be a rollback from IE 5.0 that occurred sometime back, and left IE a bit crippled - thats why I suspect some sort of comctl32 messup - which certainly could impact on toolbar functionality, styles etc - though I don't know if I've seen this happen for the command bar. Does this always occur? If you fire up your machine and don't open IE, going straight to VC instead, does that make any difference?
Thanks Tim for your reply. While searching the net I've found several identical questions about this problem. It seems that it only occurs on Win98. The problem is that comctl32.dll uses a global adress somewhere for the toolbar. This address invalidates when you debug an application. A solution is: before starting the debugger: run a application and activate a tooltip on a toolbar. Keep this application open while your debugging. This way the global adress keeps the same for as long as the application is open. This solution works fine for me now.