asked on

VB6 - How can I debug this Protection Fault?

I've written an application in VB6 that works fine on my main system, a Dell Pentium II 400 mHz machine, running Win98. I deployed it to a 486DX266 machine running Win95 to make sure I can deploy it OK. It set up fine and initially ran without a problem on the 486. Only one thing happened that is distressing. My application allows users to change default background colors; and this information is stored in the Registry. On the 486, however, about half the time when I try my color changing menu choice, I get a very nasty general protection fault, and the program crashes. All I used was the Common Dialog control to get a user's color preference, nothing fancy. Anybody have any words of wisdom on how to debug something like this? Since I'm a relative newbie, I'd appreciate a relatively simple explanation.

mark2150

Lets see your color setting code.

Can you give details about what is dying and error message.

M

tg_george

There seems to be some bugs with MS Common controls and try to get the ptches from MS site. I remeber somebody saying the COmmonCOntrol bugs a few days back on this site.

ljklinsky

ASKER

Here's the message:
"LUCIDPIX caused a general protection fault in module <unknown> at 0000:00007c2b."

Here's my color setting code:
Private Sub mnuColorsCustom_Click()
dlgLucidPiX.CancelError = True
dlgLucidPiX.Flags = cdlCCFullOpen Or cdlCCRGBInit
dlgLucidPiX.ShowColor
m_ColorChoice = dlgLucidPiX.Color
SaveSetting "LUCID_PIX", "STARTUP", "CustomColor", _
m_ColorChoice
Call UpdateColors 'Update application control colors.
End Sub

Public Sub UpdateColors()
Dim frmControl As Form
On Error GoTo ICanHandleThis
frmAbout.BackColor = m_ColorChoice
frmAbout.picIcon.BackColor = m_ColorChoice
frmAbout.cmdOK.BackColor = m_ColorChoice
frmMain.cmdDelete.BackColor = m_ColorChoice
frmMain.cmdPrint.BackColor = m_ColorChoice
frmMain.cmdExit.BackColor = m_ColorChoice
frmMain.cmdCopy.BackColor = m_ColorChoice
frmMain.cmdEdit.BackColor = m_ColorChoice
frmMain.cmdManualSearch.BackColor = m_ColorChoice
frmMain.lblFileAndPath.BackColor = m_ColorChoice
frmMain.cmdPowerSearch.BackColor = m_ColorChoice
frmPowerSearch.cmdSearch.BackColor = m_ColorChoice
frmPowerSearch.chkPowerSearch.BackColor = m_ColorChoice
For Each frmControl In Forms
frmControl.BackColor = m_ColorChoice
Next

ICanHandleThis:
Select Case Err.Number
Case 32755
Exit Sub
Case Else
Resume Next
End Select

End Sub

I'm running SP3 if that helps. I couldn't find anything on Microsoft's site. Big surprise, huh?

ASKER CERTIFIED SOLUTION

Erick37

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

mark2150

You also fall into the ICanHandleThis routine at the end of the update. You fire a RESUME NEXT without an error being present. You need an EXIT SUB just prior to the ICanHandleThis label.

The error handlers are local to each routine unless declared at the module level. So you need a ON ERROR in the mnuColorsCustom_Click() routine as Erick37 has correctly pointed. It needs to point to an error trap handler in that routine and, of course, you need an EXIT SUB prior to it to prevent "fall thru" into the error trap.

M

ljklinsky

ASKER

mark2150 and Erick37: You were both totally correct. Wow, my newbiness sure shows here. I have learned much from this. Thank you for your help. I'd like to split the points between you. Is there a way to do so?

Erick37

First confirm if this is the problem.
These errors should be caught by VB and throw a runtime error, not a GP Fault.

mark2150

erick37,

Ummm, not always. RESUME is a stack fiddler. You throw a RESUME without having had the error tripped you get stack underflow and *THAT* triggers the GPF instead of the normal exception handler.

ljklinsky, give the points to Erick37 as he was first with correct diag. Use the "Grade Comment as Answer" option.

M

Erick37

Mark,
That's good to know. I tried to reproduce a GP Fault using Resume, but VB caught it every time (even compiled into an exe). Perhaps all of the form loading that is going on in lj's coding is exacerbating the non-error Resume.

ljklinsky

ASKER

It turns out that the GPF only occurs now when I uninstall my program and then frinstall it after I update code. Seems both NT and Win95 on the dinosaur computer do NOT like the registry settings that the previous install put there. If I delete the registry entries before reinstalling, the program works fine. Now if I could only figure out how to remove the registry entries when my program uninstalls . . . Thank you both for your kind help.

mark2150

You know what key you created. Have your uninstaller delete it as part of the shutdown.

M

ljklinsky

ASKER

I don't know how to tell the deployment wizard to delete that, to tell you the truth. I'm pretty new at this. If it could delete the LUCID_PIX folder in the registry, that would do me just fine!

mark2150

Write your own little stub that kills the registry folder and *THEN* fires the uninstaller! Use the SHELL command to get the uninstaller running and then *DIE*.

M

ljklinsky

ASKER

The uninstaller works through the Control Panel, Add/Remove Programs component. It sounds like you're saying I should make my own uninstaller, not accessible from Add/Remove? Maybe I CAN write an entry to the ST6UNST.LOG when the program is first installed. Thanks for your ideas.

mark2150

Yeah, the uninstaller is a separate progam. Run yours first, then theirs.

The source to SETUP.EXE is included in your CD's. You can tinker with it to your hearts content. (Be sure to make a backup!)

M