Bizarre app crash, no trail (1 Viewer)

nfk · May 20, 2015

I have a massive Access frontend working with SQl Server and its crashing in a very dramatic way (typical APP CRASH discussed everywhere). Its is not happening randomly since its happen with only a few records.

Lets say I have 2 records on a user database:

UID Username Phone
1 Carl 65412
2 Sarah 45646

As you can see there's no difference in the two records in the way that in both cases the data is consistent with the field properties.
Then there's an Orders table and the crash happens when trying to add a new order for Sarah, every time, 10 out of 10. And there's no problem when trying to add orders to Carl.

I know this is not enough info but maybe someone has experienced similar scenario. If not I can send some money for help, I can send more details through email.

vbaInet · May 20, 2015

Sounds like a potential corrupt record. When you say it's crashing, is it actually throwing up any error messages? And do you add records using code?

nfk · May 20, 2015

"Sounds like a potential corrupt record"

It does!, except guess wut!
I grab another laptop with Office 2003, move the ADP to it and use a console to /DECOMPILE went to the VBA IDE and change the references to Office 11 (From Office 14). Compile and finally Compact and Repair. Then run the same sort of operations that were crashing on 2010 and this time it work no problem...

Now the problem is why?, why on earth would a record made it crash on 2010 but not on 2003? I cant downgrade users but I been tracing the error for ages and its just not giving me anything... Its all the same, only difference is the office version. OS is win7 pro on all cases.

The exact error message:

Rest of the blah blah

Code:

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	MSACCESS.EXE
  Application Version:	14.0.7145.5001
  Application Timestamp:	54e3dad6
  Fault Module Name:	MSACCESS.EXE
  Fault Module Version:	14.0.7145.5001
  Fault Module Timestamp:	54e3dad6
  Exception Code:	c0000005
  Exception Offset:	00350f23
  OS Version:	6.1.7601.2.1.0.256.48
  Locale ID:	2057

vbaInet · May 20, 2015

Now that you have decompiled and compact & repaired the db, you may have gotten rid of the corruption. So decompile again, set the references back to 2014, compile and compact and repair, and try it again on your original machine and see if it's back to normal.

nfk · May 20, 2015

vbaInet said:
Now that you have decompiled and compact & repaired the db, you may have gotten rid of the corruption. So decompile again, set the references back to 2014, compile and compact and repair, and try it again on your original machine and see if it's back to normal.

Already done it, goes back to same behavior. This is really as creepy as it gets...

vbaInet · May 20, 2015

Strange behaviour nfk! You may need to re-create that users records.

Going back to my other question, how are you performing this operation, through code or through a bound form?

The_Doc_Man · May 20, 2015

I'm surprised that nobody else brought this up.

Error c0000005 is an "unhandled exception" error. If you apply the "google brain" to it, you find that it is likely a memory access error. So... when you switch from Ac2014 to something older, it works. When you switch back to Ac2014 it doesn't. The question is, what changed that could lead to a memory access error? (That is rhetorical...)

Ac2014 is part of Office 2014, which comes in two flavors - 32-bit and 64 bit. If you didn't specify which one you wanted when you did the installation, you might well have gotten the 64-bit copy. The problem is that your References are not part of Access but are part of the application, so anything you created new on Ac2014 would work. But anything created on older versions and opened by the new version would almost absolutely be based on a 32-bit address. The bad news is that 32-bit and 64-bit don't always get along because not all of the Access libraries for the 32-bit versions were converted for the 64-bit environment.

Where I'm going with this is that if an address size mismatch occurs in a calling sequence, an internal subroutine call/function invocation might call an address that would cause a memory exception such as this. It is not necessarily that the specific record is causing the problem so much as the LAST record is causing the problem, because the last record has to set the recordset's <EOF> marker and the earlier records do not.

Web-search for the topic of 64-bit Office and see articles that talk about conversion from older versions of Access or Office to the 64-bit versions of same. IF the problem is just the address size, it is easy to remove Office and re-install the 32-bit version - UNLESS you have some other application that wants the 64-bit copy.

I was lucky enough that my 32-to-64 conversion was reversible because we didn't need the 64-bit version for anything else. So I got away with it. You will have to look up your other apps to see if they need to have the 64-bit version of Office. If you do not, you might try down-sizing to the 32-bit version.

nfk · May 20, 2015

Hi Doc_man, and thanks for your input...

I just tested on another laptop, this time a XP x32 running Office 2003 x32 and it seems to work fine...

I dont get it, why would it work ok on a x32 and x64 SO but when it comes to Office even when on all cases is x32 it crashes... But not all the time... out of 50000+ users I already manage to get about a 100 that would make it crash all the time and the rest give no problem trying to do exactly the same operation...

So...

Windows 7 x32 with Office 2010 x32 =

Windows 7 x64 with Office 2010 x32 =

Windows 7 x64 with Office 2003 x32 =

Windows XP x32 with Office 2003 x32 =

wtf!

vbaInet · May 20, 2015

The_Doc_Man said:
I'm surprised that nobody else brought this up.

Just me The_Doc_Man and I've been out of touch for a while

You're right about the memory access problem and I think that despite the x64 and x86 incompability issues, there are bits of code that could cause this problem.

The_Doc_Man · May 20, 2015

There is an option that has to do with "safe call" or "safe addressing" that is a 64-bit issue. It is something you add to subroutine declarations in the same category as the ByRef or ByVal option. Look that up if ever in doubt on a mixed address size configuration.

The apparently unmixed address size case of Ac2010 32-bit on Win-7 32-bit can also be a reference issue because sometimes you run into libraries that get updated to another version and some obscure library reference is broken. I know for an absolute fact that several .DLL files got updated from Ac2003 to Ac2010. Verify on the 32/32 case that no broken references exist. (If in doubt, go to a VBA screen, click Tools >> References and then scroll down through the list to see if anything says "broken reference".)

nfk · May 22, 2015

The_Doc_Man said:
There is an option that has to do with "safe call" or "safe addressing" that is a 64-bit issue. It is something you add to subroutine declarations in the same category as the ByRef or ByVal option. Look that up if ever in doubt on a mixed address size configuration.

The apparently unmixed address size case of Ac2010 32-bit on Win-7 32-bit can also be a reference issue because sometimes you run into libraries that get updated to another version and some obscure library reference is broken. I know for an absolute fact that several .DLL files got updated from Ac2003 to Ac2010. Verify on the 32/32 case that no broken references exist. (If in doubt, go to a VBA screen, click Tools >> References and then scroll down through the list to see if anything says "broken reference".)

Aloha,

I been reading a lot lately and the more I read the less it makes sense... what do you think about String, Stringstring, stringinstr and such, do you think the size of string variables could case something like this?

I cant get rid of the fact that only happen with some records... :banghead:

spikepl · May 22, 2015

Apart from the exotic explanations a more plain one is that A2007, 2010 all are less tolerant of various constructs than A2003. Also the default priority of refernces changed. The answer to your predicament could be hidden in the code: show the entire routine failing (not just snippets) and indicate the line where it fails.

nfk · May 22, 2015

So...

It starts on pressing a button that will do this:

Code:

Private Sub cmdNewVehicleOwner_Click()
On Error GoTo Error_Handler
' Retain the current Vehicle Registration No
If Not IsNull(Me.VehicleRegistrationNo.Value) Then
    gRegistrationNo = Me.VehicleRegistrationNo.Value
    gPINID = CLng(Me.CurrentPINID.Value)
    gblnCurrentCompanyRegistration = CBool(Me.blnCompanyRegistration.Value)
    gstrCurrentCallerFullName = CStr(Me.CurrentPINID.Column(1))
    ' Returns gParam3 with new Vehicle Licence No
    gVehicleRegistrationID = CLng(Me.VehicleRegistrationID.Value)
    DoCmd.OpenForm "dlgfrmAddNewVehicleOwner", acNormal, , , acFormEdit, acDialog
    ' Was the New Vehicle Owner found ?
    If Not gblnCancel Then
        Me.subfrmVehicleOwnersList.Requery
        Me.subfrmVehicleCompanyOwnersList.Requery
        Me.FindVehicleRegistrationListEntry.Requery
        Me.blnCompanyRegistration.Value = gblnNewCompanyRegistration
        ' Copy in the new Vehicle Licence No
        Me.VehicleLicenceNo.Value = gParam3
        ' Added 16 August 2011
        Me.txtReceiptNo.Value = gReceiptNo
        Me.dtmReceipt.Value = gdtmReceipt
        ' End
        'Added 28 July 2011
        If gblnNewCompanyRegistration Then
            Me.lblHeader.Caption = "This is a Company Vehicle Registration"
            Me.lblHeader.ForeColor = 255
            Me.lblCompanyWarning.ForeColor = 255
            Me.RegistrationDetails.Pages(0).Caption = "Company Details"
            Me.subfrmSubjectPersonalDetails.Visible = False
            strSQL = "SELECT * FROM dbo.comqryCompanyName"
            strSQL = strSQL & " ORDER BY [txtCompanyName]"
            Me.CurrentPINID.RowSource = strSQL
            Me.CurrentPINID.Value = gNewPINID
            Me.CurrentPINID.Requery
            Me.CompanyAddress.Visible = True
            Me.CompanyAddress.Value = Me.CurrentPINID.Column(3)
        Else
            Me.lblHeader.Caption = "This is a Person Vehicle Registration"
            Me.lblHeader.ForeColor = 0
            Me.lblCompanyWarning.ForeColor = 0
            Me.RegistrationDetails.Pages(0).Caption = "Person Details"
            Me.subfrmSubjectPersonalDetails.Visible = True
            Me.CurrentPINID.RowSource = "dbo.comqryCallerFullName"
            Me.CurrentPINID.Value = gNewPINID
            Me.CurrentPINID.Requery
            Me.CompanyAddress.Visible = False
        End If
        ' Changed 3 August 2011
        Me.subfrmVehicleOwnersList.Requery
        Me.subfrmVehicleCompanyOwnersList.Requery
        Me.FindVehicleRegistrationEntryByCompany.Requery
        Me.FindVehicleRegistrationListEntry.Requery
        Me.FindVehicleRegistrationEntryByIndexNo.Requery
        ' End
    End If
End If
Exit Sub
Error_Handler:
Resume Next
End Sub

This of course takes you to another form where you select the new person/owner and after you click the typical OK button:

Code:

Private Sub cmdAdd_Click()
On Error GoTo Error_Handler
If IsNull(Me.PINID) Then
    MsgBox "Please select the New Vehicle Owner before proceeding !", vbExclamation, gTitle
    gblnCancel = True
    Exit Sub
End If
Me.Warn1.Visible = False
Me.Warn2.Visible = False
blnWarn = False
If IsNull(Me.txtReceiptNo.Value) Or Me.txtReceiptNo.Value = "" Then
    Me.Warn1.Visible = True
    blnWarn = True
End If
If IsNull(Me.dtmReceipt.Value) Or Me.dtmReceipt.Value = "" Then
    Me.Warn2.Visible = True
    blnWarn = True
End If
If Not IsDate(Me.dtmReceipt.Value) Then
    Me.Warn2.Visible = True
    blnWarn = True
End If
If blnWarn Then
    Exit Sub
Else
    Me.Warn1.Visible = False
    Me.Warn2.Visible = False
    blnWarn = False
End If
If CBool(Me.blnNewCompanyRegistration.Value) Then
    strMsg = "You have chosen a 'Company Registration'" & vbNewLine & vbNewLine
Else
    strMsg = "You have chosen a 'Person Registration'" & vbNewLine & vbNewLine
End If
strMsg = strMsg & "Are you sure you want to do this ?"
If MsgBox(strMsg & vbNewLine & vbNewLine & "You cannot change it afterwards !", vbQuestion + vbYesNo + vbDefaultButton2, gTitle) = vbYes Then
    gParam1 = Me.CurrentPINID.Value
    gParam2 = gRegistrationNo
    ' Added 2 August 2011
    gParam3 = Me.VehicleLicenceNo.Value
    ' End
    ' Append the current Vehicle Owner to the list of previous Owners
    'Call AddNewVehicleOwnerEntry(CLng(Me.CurrentPINID.Value), gRegistrationNo, Me.txtReceiptNo.Value, Me.dtmReceipt.Value, CBool(Me.blnCurrentCompanyRegistration.Value))
    Call AddNewVehicleOwnerEntry(gVehicleRegistrationID, gblnCurrentCompanyRegistration)
    ' This is the new Vehicle Owner
    gNewPINID = CLng(Me.PINID.Value)
    If Not Me.chkManual.Value Then
        ' Increment the Vehicle Reg No
        Call RunSP("usp_UpdateNextVehicleLicenceNo")
        ' End
    End If
    Me.Cancel.SetFocus
    Me.cmdAdd.Enabled = False
    gblnCancel = False
    ' Added 10 August 2011
    gblnNewCompanyRegistration = CBool(Me.blnNewCompanyRegistration.Value)
    ' End
    ' Added 11 August 2011
    Call AppendArchiveVehicleExciseLicenceWithCurrentOwner(CLng(Me.CurrentPINID.Value), gstrIndexNo)
    Call UpdateVehicleExciseLicenceWithNewOwner(CLng(Me.CurrentPINID.Value), gNewPINID, gstrIndexNo, gblnNewCompanyRegistration)
    ' End
    ' Added 16 August 2011
    gReceiptNo = Me.txtReceiptNo.Value
    gdtmReceipt = CDate(Me.dtmReceipt.Value)
    ' End
    DoCmd.Close
End If
Exit Sub
Error_Handler:
Call ReportError(gOfficerFullName, Err.Description, Err.Number, "cmdAdd_Click")
End Sub

This closes the form and then goes to:

Code:

Me.lblHeader.Caption = "This is a Person Vehicle Registration"
Me.lblHeader.ForeColor = 0
Me.lblCompanyWarning.ForeColor = 0
Me.RegistrationDetails.Pages(0).Caption = "Person Details"
Me.subfrmSubjectPersonalDetails.Visible = True
Me.CurrentPINID.RowSource = "dbo.comqryCallerFullName"
Me.CurrentPINID.Value = gNewPINID
Me.CurrentPINID.Requery
Me.CompanyAddress.Visible = False

I noticed that this doesnt happen if I comment the Me.CurrentPINID.Value = gNewPINID line, but if I comment that the changes dont take effect and its impossible to track after that, I mean why? what difference could It make... Frustrating

spikepl · May 22, 2015

Err so where does it crash? IT is not clear where it happens. What does "its impossible to track after that" mean? Did you try to step through with the debugger?

Also, where are your variable declarations? Do you have Option Explicit in your modules?

nfk · May 22, 2015

spikepl said:
Err so where does it crash? IT is not clear where it happens. What does "its impossible to track after that" mean? Did you try to step through with the debugger?

Also, where are your variable declarations? Do you have Option Explicit in your modules?

Truth be told this is so massively monstrous it would take for ages to put every single bit related...

Yes I stepped through the whole thing using the god forsaken Access debugger (if you can actually call it that way)...

This is just insane... as a matter of fact lets just put it this way, I wish the developer would have died many years ago instead of leaving this bleeding pile of crap. As soon as I can I will go to hes grave in the UK ad take a piss on him and his MVP badge.

spikepl · May 22, 2015

I still think the explanation could be the lesser tolerance of the newer Access version , perhaps in type converisons since you do not seem to have the DAO/ADO ambigous declarations, and since the data is digestible for the old version.

But without detailed walk-through of the code I can only help you with curses and incantations

DavidRBoyle · May 22, 2015

The behaviour you have described is almost certainly due to something that happens in the crash scenario but not the other.

That is easy enough to debug and get to the bottom of once you have the experience to know what you're doing you can identify the line of code that crashes the app and then think through why. The fact that you don't isn't grounds on which to insult the original designer.

vbaInet · May 22, 2015

DavidRBoyle said:
The fact that you don't isn't grounds on which to insult the original designer.

Ditto!
But to be honest, it's not the best looking code though

So nfk, when you step through the code, you also need to "watch" the values and look in the Locals Windows.

GinaWhipp · May 23, 2015

Please list the References you have checked when opened in Access 2010. Because... it might just be one of those id the culprit, have a look here...
http://www.access-diva.com/d5.html

Bizarre app crash, no trail (1 Viewer)

Registered User.

AWF VIP

Registered User.

AWF VIP

Registered User.

AWF VIP

Immoderate Moderator

Registered User.

AWF VIP

Immoderate Moderator

Registered User.

Eledittingent Beliped

Registered User.

Eledittingent Beliped

Registered User.

Eledittingent Beliped

Registered User.

AWF VIP

AWF VIP

Similar threads

Users who are viewing this thread