Crash on breakpoint

[pdanes]

I have an app that has recently developed an extremely annoying trait – it crashes and closes on breakpoints. I set a breakpoint, as I always have, the code gets to that point, stops, the VBA window appears with the line highlighted, perfectly normally, then a few seconds later, Access just closes. This has always been an occasional treat, but pretty rare – maybe once a month, and usually after doing a bunch of stuff that is generally frowned upon, like editing running code. But this app has suddenly started doing it all the time, so much that setting a breakpoint is no longer a useful operation, but a guaranteed unsaved shutdown. Multiple C & R, decompile, C & R again - no help.

It's not always on one line, or one type of line. If there is anything in common with the places it does this, I have been unable to find it.

 

[GPGeorge]

A corrupted accdb pops into mind with symptoms of that sort...

Try a decompile/compile on it.

 

[pdanes]

A corrupted accdb pops into mind with symptoms of that sort...

Try a decompile/compile on it.

Please see last sentence in first paragraph of my post.

 

[CJ_London]

editing running code is a big no-no. You can lose everything and is indicative of the behaviour you are seeing.

neither compact/repair nor decompile/recompile guarantees fixing your problem.

I would create a new db then in order and taking the opportunity to not import anything that is no longer required. Note do not copy/paste.

1. import any unlinked tables if any and/or create new linked tables to the BE
2. import queries
3. import modules
4. import forms
5. import reports
6. import macros

any imports that fail imply a corruption issue. The best solution is to recreate the relevant object rather than trying to fix it.

next
7. compact/repair
8. compile
9. set db defaults such as form on open, window options, etc
10. run your app - hopefully any issues will have gone away. If they haven't then the implication is there is something wrong with your code

edit: consider using Stop rather than a breakpoint - remove or comment out when done. There is also debug.assert for a conditional stop

And I hope you have Option Explicit at the top of every module

 

[The_Doc_Man]

Open Event Viewer next time this happens and see if anything is listed when running MSACCESS.EXE as the primary task. If there is an error code or status, it will begin with either 800 or C00 and will be 8 characters long, in the format of a hexadecimal number. The system error events are sorted by time so if you know the system time of the crash it will be easy to find something in the error logs.

If you have the option to repair your Office installation, it might be a good time to do so. Also, double-check that your VBA >> Tools >> References doesn't include a broken or missing reference.

 

[pdanes]

editing running code is a big no-no. You can lose everything and is indicative of the behaviour you are seeing.

neither compact/repair nor decompile/recompile guarantees fixing your problem.

I would create a new db then in order and taking the opportunity to not import anything that is no longer required. Note do not copy/paste.

1. import any unlinked tables if any and/or create new linked tables to the BE
2. import queries
3. import modules
4. import forms
5. import reports
6. import macros

any imports that fail imply a corruption issue. The best solution is to recreate the relevant object rather than trying to fix it.

next
7. compact/repair
8. compile
9. set db defaults such as form on open, window options, etc
10. run your app - hopefully any issues will have gone away. If they haven't then the implication is there is something wrong with your code

edit: consider using Stop rather than a breakpoint - remove or comment out when done. There is also debug.assert for a conditional stop

And I hope you have Option Explicit at the top of every module

Yeah, I was hoping to not have to go that far, but I may have to. It's aggravating though, because the app works fine. It's only the debugging when I'm making some changes for the user that I run into this. And yes, I do use Option Explicit everywhere.

 

[GPGeorge]

Yeah, I was hoping to not have to go that far, but I may have to. It's aggravating though, because the app works fine. It's only the debugging when I'm making some changes for the user that I run into this. And yes, I do use Option Explicit everywhere.

Which is the greater annoyance? Creating a clean new accdb or having to restart the current accdb repeatedly?

 

[pdanes]

Open Event Viewer next time this happens and see if anything is listed when running MSACCESS.EXE as the primary task. If there is an error code or status, it will begin with either 800 or C00 and will be 8 characters long, in the format of a hexadecimal number. The system error events are sorted by time so if you know the system time of the crash it will be easy to find something in the error logs.

If you have the option to repair your Office installation, it might be a good time to do so. Also, double-check that your VBA >> Tools >> References doesn't include a broken or missing reference.

References are all okay. I don't think it would even compile if there was something wrong with a reference. And it's only this one app - other Access apps on the same machine work fine. I haven't tried this app on a different machine, though. That's probably worth a look, although I'm not sure what it would tell me either way. I'll take a look at the event viewer.

 

[CJ_London]

Yeah, I was hoping to not have to go that far, but I may have to.

Doesn’t take that long - 10 to 15 mins tops (assuming no issues are found) . It’s something I usually do before releasing an app to user testing to clear out all the rubbish

 

[MarkK]

If you post the database, I'll rebuild it. I wrote code to export each object to text file, and read it back into a new database file, so it is pretty fast.

editing running code is a big no-no.

Also, I edit running code all the time. Maybe it's a no-no, but if you clear the compiler settings indicated below, you dramatically reduce the chance your in-process edits will leave the file in an irregularly compiled state.

 

[pdanes]

If you post the database, I'll rebuild it. I wrote code to export each object to text file, and read it back into a new database file, so it is pretty fast.


Also, I edit running code all the time. Maybe it's a no-no, but if you clear the compiler settings indicated below, you dramatically reduce the chance your in-process edits will leave the file in an irregularly compiled state.

View attachment 117636

Thank you for the offer, but the import is not really that big a deal. That was more of a background whine on my part. The only hassle is that I have some custom document properties set, and Access's built-in import function doesn't handle those. I don't know why not - it seems a rather obvious thing to include. I wrote my own little routine to do it, so I wouldn't have to copy them manually, but it's an extra and unnecessary step. Just one of the things I wish the Access developers would fix.

Also, there is a pretty good chance that my app would bork on your machine. It's in Czech, and apps built in foreign version of Access often throw fits when loaded onto an English-only computer. But again, the import really isn't that much of hassle - I can handle it.

I didn't know about the compile flags, though. I do the same as you - regularly edit running code. I know it's frowned upon by purists, and once in a while, it craps out on me, but the convenience of being able to modify something while it's running is so great that I will put up with the occasional crash. Every time it happens, I become a little more conscientious about saving my work before continuing execution, at least for a little while. I just checked and I do have those flags set, so I'll try clearing them and see if it helps. I pretty much always do a manual compile immediately after an edit, to make sure I didn't write in some obvious garbage, so clearing that shouldn't impact my established routine in any way. I just need to remember to SAVE after compile, for those rare occasions when Access decides to throw a fit.

And I think I may have tracked down what was causing my newly-found crashes. I have a class module opening a form, and the crashes seem to be mostly coming in code that runs after the class module's form closes, but while the class module instance still exists. I'm going to dig into that and see if I can confirm that is the common factor.

 

[NauticalGent]

I wrote code to export each object to text file, and read it back into a new database file, so it is pretty fast.

 

[NauticalGent]

but if you clear the compiler settings indicated below, you dramatically reduce the chance your in-process edits will leave the file in an irregularly compiled state.

Mark, could you expound a bit on this?

 

[Pat Hartman]

Also, I edit running code all the time. Maybe it's a no-no, but if you clear the compiler settings indicated below, you dramatically reduce the chance your in-process edits will leave the file in an irregularly compiled state.

I confess. I do also, but I have lost edits in the process. You must be very careful and check to make sure your changes actually got saved. When I edit running code. I ALWAYS explicitly save it AND compile it before running it and that helps but there are situations where the code still doesn't actually save but I've never been able to pin it down.

 

[The_Doc_Man]

Often when I try that, it tells me that the action I am about to undertake (not the exact wording) will reset execution. Of course that means that all the public variables will be reset.

 

[MarkK]

Mark, could you expound a bit on this?

With Compile on Demand enabled, the compiler is optimized for performance in two key ways: 1) It will only compile code on the current execution path. 2) It will preserve previously compiled code. As I understand it, this can lead to crashes because you might edit the signature of procedure, but modules with code that consume that procedure may not be recompiled.

If you turn those compiler settings off, the entire project is always entirely recompiled before execution. I find I get way fewer crashes with Compile on Demand turned off.

I can think of four places I lose edits: 1) Access crashes with unsaved edits in the IDE. 2) A form opened with the acDialog switch (possibly also true of a form that is opened as Modal). If you edit code in such a form and you explicitly save your edits they will be saved, but if you close this form, or it crashes, unsaved edits are lost without prompts to save. 3) Edits to code in a non-default instance of a form, same as 2). Explicitly saved edits are saved, otherwise everything is lost without prompts. 4) Edits to code in a referenced MS Access Library file. This one it a pain, because these edits are only lost (without warning) after you close the application, so if your library raises an error, breaks into the debugger, you see the error, fix it, but don't realize you were in the library. This edit continues to work correctly for the duration of the current session, but next time you open the app, you get the same error you know you already fixed. For this you must close the current application, and open the Library exclusively, make your edits, close the library, and re-open the app.

Oh, and one more, close a form that initiated execution into a bunch of class modules. The form calls a procedure in another class, which may call into a bunch of other classes. Execution breaks on error or breakpoint, you do some work, edits, comments, tidy up, phone rings, whatever, you close the form, and continue execution in the class. Access crashes when execution returns to the closed form, still present in the call stack, but closed.

Also, Happy New Year all!
Cheers,

 

[NauticalGent]

With Compile on Demand enabled, the compiler is optimized for performance in two key ways: 1) It will only compile code on the current execution path. 2) It will preserve previously compiled code. As I understand it, this can lead to crashes because you might edit the signature of procedure, but modules with code that consume that procedure may not be recompiled.

If you turn those compiler settings off, the entire project is always entirely recompiled before execution. I find I get way fewer crashes with Compile on Demand turned off.

I can think of four places I lose edits: 1) Access crashes with unsaved edits in the IDE. 2) A form opened with the acDialog switch (possibly also true of a form that is opened as Modal). If you edit code in such a form and you explicitly save your edits they will be saved, but if you close this form, or it crashes, unsaved edits are lost without prompts to save. 3) Edits to code in a non-default instance of a form, same as 2). Explicitly saved edits are saved, otherwise everything is lost without prompts. 4) Edits to code in a referenced MS Access Library file. This one it a pain, because these edits are only lost (without warning) after you close the application, so if your library raises an error, breaks into the debugger, you see the error, fix it, but don't realize you were in the library. This edit continues to work correctly for the duration of the current session, but next time you open the app, you get the same error you know you already fixed. For this you must close the current application, and open the Library exclusively, make your edits, close the library, and re-open the app.

Oh, and one more, close a form that initiated execution into a bunch of class modules. The form calls a procedure in another class, which may call into a bunch of other classes. Execution breaks on error or breakpoint, you do some work, edits, comments, tidy up, phone rings, whatever, you close the form, and continue execution in the class. Access crashes when execution returns to the closed form, still present in the call stack, but closed.

Also, Happy New Year all!
Cheers,

Thanks, and Happy New Year to you and yours as well!