Samapico 08-28-2009, 12:23 PM I have this bug... In the IDE, I sometimes (not always) get a fatal IDE crash with no error message, except the 'send report / don't send' dialog thing. If I try to debug the problem with F8 during the unload process, it goes all the way through the Form_QueryUnload, then it terminates a bunch of classes and controls... and sometimes it crashes.
When compiled, it always crashes when closing the EXE.
Is there a way to pinpoint the bug? I tried stop points at every custom control terminate event, without much success... It's still pretty ***-inducing, never crashes at the same place, sometimes doesn't crash at all. Also, there is absolutely no particular code in these terminate events...
Any tips on debugging such a pain in the *** bug?
My program uses some VBaccelerator controls that use a lot of subclassing, mainly the OfficeToolbar / Dock thing / Image list / coolmenu. All of these are kind of interleaved together.
My program also deals with a lot of memory DC's and bitmaps
I could give the offset addresses it give me when it crashes... not sure if it could help. I'll have to get back home first though, in a few hours.
fisolofee 08-28-2009, 12:52 PM I believe the reason for your IDE crashing is because of those user controls. The main problem only occurs when unloading (more frequently if in an improper manner)..
The same problem occurs with Codejock controls.. but with those, the compiled EXE turns out just fine.
Maybe if you post some code or a small dummy project to reproduce the bug (assuming of course that you would like to keep your current project code private), then the matter could be further looked into.
Take a look at this for some solutions to codejock's problems:
https://forum.codejock.com/forum_posts.asp?TID=4782
Anyway, I went further and found for you a solution that is available on the vbAccelerator website itself:
http://www.vbaccelerator.com/home/vb/code/libraries/subclassing/SSubTimer/article.asp
Enjoy the hacks ;)
Samapico 08-28-2009, 04:47 PM The controls/ocx I use already use the SSubTmr thing though :(
The project I'm working on is open-sourced, actually. But it's pretty huge...
Emmm, I think I might have an idea of what causes the problem... I have a custom control that uses the setParent API to show a picturebox popup over other stuff... and I put that control on a Frame, then I dock that Frame on the vbaccelerator DockToolbar thing (vbalDkTb6.ocx), which basically grabs the hWnd of the Frame... So I'm guessing I have to do something about it using the SSubTmr thing............ Not sure what though :P
... ok this sucks.
Start project, stop *crash*
Comment out the setparent calls in my custom control, start, stop, *crash*
Comment out the part where the Frame is docked, start, stop, no crash
Uncomment the part where the Frame is docked, but get the suspected control off the frame, start, stop, no crash (hmm, sounds good, right?)
Put the suspected control back on the frame, start, stop, no crash (wut??)
Trial and error sucks, but at least it should work... but as you see, it never does the same thing sooooooo...
gibra 08-28-2009, 05:49 PM Caution...
I discovered that some vbAccelerator controls no longer works with Windows XP - SP3 (i.e. CommandBars)
Also, be sure don't use End statement.
Samapico 08-28-2009, 08:42 PM So if I expect my program to work on vista / win7 or whatever... I should switch to C# or something? :P
fisolofee 08-29-2009, 06:14 AM If you read the page I linked for you at codejock, you'll see that this similar problem has been solved in some very strange ways.. For example, there was one person who simply solved the problem by changing the control focus before unloading the forms..
Are you sure you are unloading properly? First of all, pressing the "stop" button is not a very good idea. It's basically the same as using an "End" statement - which is terrible in the sense that your controls and forms will not unload and properly clear from memory (..memory leaks..)
VB6 is compatible with vista and Windows 7 I believe. There are only some minor issues.. but I believe switching to Vb.Net is the way to go. I'll be moving over soon :)
Anyway, back to the main topic. How are you unloading? Does it crash again after the changes you made above?
Samapico 08-29-2009, 10:23 AM I never stop the project with 'Stop' because it does indeed screw up everything. I close the MDI form and everything gets unloaded.
It does still crash sometimes... but for example, right now it's back as it was before and it doesn't crash...
And yes, my program works on Vista, with some issues however... And it should work fine on win7 because it has XP compatibility. But after that, it shouldn't work much :P
And if I port my program to something else, I'd rather move to C# or even C++ than VB.net :P It's a pretty big program (~30k lines of code) and a lot of features are still being developed... So moving over will be a huge project :S
Edit: Reading the codejock link... I clicked to focus on the docked control kind of like they talk about, and it crashed!
Samapico 08-29-2009, 11:21 AM I HATE how it's not consistent at all. I was going in the same direction as this post:
I am using Codejock Controls 10.1 an i have the same problem - here my
solution (dont know, if its really the problem):
i put on my form a textbox behind all controls (visible!) - and in the form_unload
event, i set at first the focus to the textbox: the IDE dont crash anymore.
At this point, I get consistent crashes if I click in my form and change the focus, then close. If I don't touch anything and close I get no crash.
I add a visible textbox, give it focus before unloading, and WOW, no crash.
I remove the setfocus line, try again... wth still no crash?
Edit: I can still get crashes with the setfocus thing, though.
Cerian Knight 08-29-2009, 02:14 PM You might be interested in 'Safe Subclassing':
http://www.xtremevbtalk.com/showthread.php?t=285517
The next most common cause of crashes is related to recursion and/or allowing object references to occur subsequent to a DoEvents call that handled, for example, a Form Unload event. Improper use of DoEvents is rampant in many projects I've looked at. After inspecting such code, it becomes obvious why random crashes are reported. Let me know if this is relevant, granted that subclassing is hard enough to deal with all by itself.
Samapico 08-29-2009, 04:50 PM This might be a good time to remind you all that the compiled exe also crashes after exiting...
AppName: dcme3500.exe AppVer: 3.5.0.0 ModName: msvbvm60.dll
ModVer: 6.0.98.2 Offset: 0004c2f5
If that can help in any way...
I just did a search on all the DoEvents, by just starting the project and stopping it there should not be a single one that gets executed.
gibra 08-30-2009, 12:20 AM Can you send a project (zip) tha reproduce the issue?
Samapico 08-30-2009, 09:57 AM Any reason why this forum doesn't allow rars?
I have no idea how the references will work, you might have to redefine them, I don't know...
Project is pretty big so... good luck
Start it, click-drag around a bit, close it; it might crash.
The MDI form is frmGeneral, if you need to mess around with it
If the crash happened consistently, I'd just thin down the project to find the crashy part or combination... but it's pretty useless because it seems to decide when it feels like crashing or not
We were planning to port the project to another language eventually anyway... it became way bigger than was initially planned. It's a bunch of things added on top of each other, so it became relatively messy (and **** you lack of inheritance). So if this is too much trouble, I'll just revert back to before I implemented those vbaccelerator controls and start anew.
gibra 08-30-2009, 04:52 PM Sorry,
in my Windows XP SP3 I can't load project because some vbAccelerator controls no longer work (as already written).
Samapico 08-30-2009, 05:59 PM ô.o
I have SP3 as well... When I get errors on load, I just go re-fix the references and components, then reopen it and it usually works
Cerian Knight 08-31-2009, 09:08 AM I haven't gotten past this (from .log):
Line 43: Cannot load control dockRight; license not found.
Line 53: Cannot load control dockLeft; license not found.
Line 63: Cannot load control dockBottom; license not found.
Line 75: Cannot load control dockTop; license not found.
Samapico 08-31-2009, 09:36 AM Hmm, I didn't include the vb projects of the vbaccelerator controls cause it wouldn't fit with the 2MB max upload...
Try this:
http://www.sendspace.com/file/4jakez
Cerian Knight 08-31-2009, 05:40 PM I had already run the vbAccelerator .vbg project which I downloaded myself. Same issue.
I'm working on manually registering the dll/ocx's. Maybe that will work.
Cerian Knight 09-02-2009, 06:44 PM I manually regsvr32ed the dlls and am able to reproduce the crash on exit in the IDE nearly 100% of the time under WinXP SP3 if I just load the project and run it. I have found that I can elimate the crash by removing the llRegionList LayerList control from frmGeneral (and all code references to it). I further verified that limiting Processor Affinity to just 1 CPU has no benefit and the mere presence of llRegionList without code references will cause the crash.
On a hunch, I loaded the project on an old 1GHz Win2K system (without running it) and witnessed the IDE and Taskbar icons flickering. Upon deleting the LayerList control from the form, the flickering immediately stopped. Oddly enough, this system does not crash when exiting the program. My old ATI AIW 128 Pro AGP video card often proves useful in hinting at such problems, due to some of its hardware/driver quirks.
I hope this helps. If you need further help with this, I can set some breakpoints in the UserControl code to see what it is doing just 'sitting there'. I don't have time now though. I hate managing UC behavior, so I avoid them like the plague.
Samapico 09-02-2009, 10:36 PM Thanks a lot!
I had noticed the flickering also; It only happened if there was a graphic form opened in the IDE.
When I was talking about a 'suspicious control' in my earlier posts, I was actually talking about the region list. I have to say I didn't try completely removing it...
Again, thanks a lot for the time you spent on this
|