Migrate Access 2010 to Access 2013 - Application Crash - not able to trap error (1 Viewer)

Access 2013 has an Application Crash and error that will not fail on Access 2010. Logging this to draw others who might have something like this.
It is also a warning to anyone considering upgrading from Access 2010 to 2013. The application is around 65 MB of forms and complex regulatory code behind the forms with data on SQL Server Linked tables.

Development: Desktop 32 bit Access 2010 - now 32 bit Access 2013 (Both latest SP)
Deployment: Citrix Xen - Citrix has a Server running the same version of 64 Bit MS Access.

On the desktop, a blank Access 2013 DB was created. Imported all objects from Access 2010 version. Set DB Properties to match. Deploy on Citrix 2013.
No problems. Also added conditional compiles for all API calls. No problems.

After around 3 weeks, a random application crash for one single form begin to happen. The Form consist of a Form, Tab Subform and a subform with a lot of rule based form vba.
Note: One PC has Office Access 2010. This form absolutely will not crash on Access 2010 workstation.
The crash can be recreated on the Citrix Access 2013 and Desktop 2013.
Multiple records can be added (one to many). A pull-down field value that is actually the second update to a field in the recordset is consistent in causing the crash. After the crash - the data chosen is actually in the record.

This code was working in a form module for two years. It still works perfectly in Access 2010. It compiles in both Access 2010 and 2013.
Around 50 other forms appear to work fine.
Note: this error can not be trapped. Also, if the code is stepped through in the vba code module, it will not error.

After some other deadlines are complete, more time will be spent including any fix or interesting observation. Perhaps someone searching the internet will find this error and contribute.

Problem signature:
Problem Event Name: APPCRASH
Application Name: MSACCESS.EXE
Application Version: 15.0.4569.1503
Application Timestamp: 52b0c5f8
Fault Module Name: acedao.dll
Fault Module Version: 15.0.4569.1503
Fault Module Timestamp: 52b0bead
Exception Code: c0000005
Exception Offset: 0000000000032375
OS Version: 6.1.7601.2.1.0.16.7
Locale ID: 1033
Additional Information 1: 431b
Additional Information 2: 431bb22d893c6180b06f244372ea8d2b
Additional Information 3: 79b0
Additional Information 4: 79b057b25e51421c07a75b8e557e209c

Evidently this might possibly be an unresolved issue since July 2014
http://answers.microsoft.com/en-us/...33-25fb8b30ff30?auth=1&rtAction=1456763831740

I had something similar. No matter what, the new version would crash.
Reinstall/repair...nothing helped.
When I used a DIFFERENT PC, it worked. That 1 pc did not like Access, or DB.

Thanks! I have tried 2 Dell PC, close but different models. Had one wiped, reinstalled Windows 7 and Office.
Plus, the Citrix servers run 64 Bit OS - different hardware - 64-Bit MS Office.
They just moved the Citrix from one set of hardware servers to another.

While this statistical pool isn't huge, it still would seem to be a Access 2013 issue.
Reminder: when the Production and Test Citrix Servers hardware were running Access 2010 (before they were updated to Office 2013) the error did not happen.
Also, after reinstalling Office 2010 on the workstation, there is no problem.

Thanks for your input! More input will hopefully lead to some indication.

Development: Desktop 32 bit Access 2010 - now 32 bit Access 2013 (Both latest SP)
Deployment: Citrix Xen - Citrix has a Server running the same version of 64 Bit MS Access.

Click to expand...

Not up on the details of Citrix Xen but if it weren't a Citrix case, my knee-jerk reaction would be that you have a 32-bit app file running on a 64-bit utility. There is a known problem having to do with "ptrsafe" options in calls because when you pass an object through a subroutine interface, that is actually a pointer to the object, not the object itself. That pointer (address) has a different format for 32-bit and 64-bit Office. Oh, it can be made to work, but you have to scrupulously visit any/all subroutines/function to assure that all pointers are made "pointer-safe."

Another "gotcha" is that Microsoft did not implement identically-functioning DLL files between 32-bit and 64-bit cases. Not that a given subroutine doesn't have the same description in 32-bit and 64-bit cases, but there is no guarantee that all of the 32-bit DLLs got ported to 64-bit.

I cannot begin to answer why Ac2010 works and Ac2013 doesn't other than the odd chance of DLL issues between the two versions.

Since I am not familiar with the Xen servers, let me ask a stupid question. Is it possible to remove the 64-bit Office and put 32-bit Office on the Xen server? Even if only for a test?

Good questions, it keeps me thinking and rethinking the situation.

The Citrix is just a ICA Presentation layer. The Windows Remote Terminal is a license from Citrix. The only reason Citrix is important is that it isn't some 3rd party Java freeware. If using any tool like VNC Viewer to the server, it fails the same... but only on Office 2013.

The Office 2010 32 or 64 Bit works fine on either a desktop (Windows 7) or Windows Server. The Office 2013 32 or 64 Bit fails on both desktop and server.
Both versions of Office compile.
The Office 2013 doesn't fail if the step through code is used in the VBA window. Only if it runs at normal speed.

After finishing my next deadline I will do the following (thanks to a 5 year response by Bob Larson). After upgrading from Access 2000 to Access 2007, something strange kept happening. Bob suggested I delete the control, add a new control, name it the same, and add the old code back. At first it sounded strange. However... one can't knock success. Will be back after finishing an important task.

Thanks for everyone's patience. This has seemed to have solved the problem. The attachment displays 2 ways to determine if Access 2013 SP1 is installed. Looks to me like Microsoft can't be consistent?

History: this code worked just fine on Access 2010. It compiled just fine on Access 2013. Step-by-Step in code it worked fine in Access 2013.

Add New Process: On a New Record - there are 3 required fields. The Cancel Update event runs until all 3 fields are completed. Then, depending on a bunch of rules, three items get filled in with the right data plus a ComboBox opens requiring a custom list (depending on previous data entered) to be completed.
Once the user completes the choice in the Combo box, the focus moves to the next field and the record was updated.

In Access 2015 The AppCrash occured as soon as the Combobox was entered. The Record was in fact saved. But the entire application crashed.

After adding some DoEvents at "busy" places, the Desktop Access 2015 seemed to stopped the AppCrash. But, who knows? Perhaps the network speed for the SQL Server Linked Tables just improved from the desktop?
From that point, the code was changed and tested on the Citrix Application Server that did continue to crash constantly. It always crashed when the ComboBox selection was made on a New Record.

The form wizard automates a status for State and/or Federal.
The code in the ComboBox row for each State and Federal is almost identical. The App Crash was constant as well. That made it easy to test.

Solution: Once the SetFocus was moved to the end of the ComboBox After Update event for the State, the AppCrash stopped for the State but was consistent for the Federal. Once the Set Focus was moved to the end on the Federal code, it also stopped!

This code was running on Access 2010 since 2013 with out issue.
It would still run on a workstation and a server with Access 2010.

Analysis:
In retrospect, using a setfocus in a bound form before a record update inside the After_Update event of a combobox wasn't a great idea. But, the code did work fine.


Me.txtStExpireDt.SetFocus was moved from before the acCmdSaveRecord to after it.

Update:
24 hours later, no AppCrash.
Before that, it was between every record to about every 4th record.
Around 6 concurrent data entry people just on that one form catching up on backlog.