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.