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.
ljklinskyAsked:
Who is Participating?
 
Erick37Connect With a Mentor Commented:
Probably unrelated:

You use CancelError in the dialog routine without an On Error statement to handle the situation where the user cancels the dialog box.
0
 
mark2150Commented:
Lets see your color setting code.

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

M
0
 
tg_georgeCommented:
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.
0
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

 
ljklinskyAuthor Commented:
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?
0
 
mark2150Commented:
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

0
 
ljklinskyAuthor Commented:
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?
0
 
Erick37Commented:
First confirm if this is the problem.
These errors should be caught by VB and throw a runtime error, not a GP Fault.
0
 
mark2150Commented:
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
0
 
Erick37Commented:
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.
0
 
ljklinskyAuthor Commented:
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.
0
 
mark2150Commented:
You know what key you created. Have your uninstaller delete it as part of the shutdown.

M
0
 
ljklinskyAuthor Commented:
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!
0
 
mark2150Commented:
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
0
 
ljklinskyAuthor Commented:
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.
0
 
mark2150Commented:
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
0
All Courses

From novice to tech pro — start learning today.