0

I asked a similar question here: How to diagnose MS access crashes so I apologize if there is a better way to ask a closely related question. I have been having crashes in an MS access database that we use extensively in our business. We have narrowed one crash down to a very odd behavior -- when a certain form is opened, and the user opens a new email from MS outlook that will cause MS Access to have a hard crash and close completely. This behavior only seems to happen in Office 2013. Is there any way to determine what is causing this crash?

Community
  • 1
  • 1
Steven Deam
  • 567
  • 1
  • 7
  • 21
  • Run the app in the debugger, and have someone send you the same email when the same form is open. Other than that, without the code involved in that "certain form" and an idea of what it does, no one can help you here. You haven't even described what "having crashes" means at all. – Ken White Jul 25 '13 at 18:22
  • At the time of the crash, no code should be running -- the form can be sitting idle for hours, but if we create a new email in outlook the entire Access program will crash. I I say in a comment below here, we have error handing and recording in every function in our code and it does not catch the error, making us believe that the error is happening outside of any code that we have written. 'having crashes' in this case means that Access itself has an error and the entire program shuts down. The windows event log shows error in MSCOMCTL.OCX, which I do not know how to debug – Steven Deam Jul 29 '13 at 15:23

2 Answers2

1

I'd think that the best way to handle more unexpected/ unaccounted for bugs is to set up some form of error handle logger like the one suggested by Allen Browne http://allenbrowne.com/ser-23a.html

The basic idea is that you have your normal error handling routine but rather than just showing the user the error number in a messagebox you:

  • On error # that I am familiar with do this
  • On error #2 that I am familiar with do this
  • If something unexpected happens write information about the error (you can also capture additional info here that might be helpful in debugging like code line references)

This will not only allow you to fully document your issues (rather than relying on just the error messages and remembering them etc.) it also makes it that your users who are experiencing crashes but do not have access to the modules to collect the error data for you! Unfortunately it isn't possible to replicate every issue the users experience, so it's great to be able to capture that information in a table and have 50 users collecting bug information for you!

I will not quote his article here but I highly recommend you give it a shot :)

WillGetItDunn
  • 81
  • 6
  • we have error handling and reporting in all of our functions throughout the database. The crashes I am talking about seem to be Access program level rather than custom code -- I am thinking that an Office dll is causing the problem, but can't come up with a way of tracking that down. – Steven Deam Jul 29 '13 at 14:17
0

See this answer. Specifically, the Remove Binary Data from Form section will apply.

CL.
  • 173,858
  • 17
  • 217
  • 259
DHW
  • 1,176
  • 1
  • 15
  • 30