John C. Flackett

I’m happily going about my software development duties (and writing some cool updates to a large MS Access software product) when the whole thing crashes with an unexplainable error (I’ll tell you why it’s unexplainable later on). Oh, no! I really should have backed-up sooner!

Extensive debugging of the new code shows absolutely no issues – in fact, the “Bad DLL calling convention” error occurs when a new function returns a perfectly acceptable Boolean….what is going on?

The Problem

Running my ‘perfect‘ code, MS Access gives me an Error49:

“Bad DLL calling convention“

However, debugging tells me this error is incorrect…unless returning a Boolean from a function is now a terrible thing for a DLL that doesn’t even exist??

Obviously, because it’s MS Access, these sorts of things happen every once in a while, so you reach for your standard toolkit of:

Tools->Database Utilities->Compact and Repair Database...

Surprise, surprise this doesn’t make any difference at all (and now I’m getting really annoyed cos Access keeps crashing and I have to keep firing it up again). So, thinking about the problem more carefully (which, of course, you should do in the first place), what does the error tell me?

References?

Well, the obvious place to start looking for a real solution is in the Library References (just in case you’re new to this, open any Module and then go to: Tools->References...). It’s possible that, for some reason, a reference to a library has broken and is displaying ‘Missing’ at the beginning.

Suffice to say, all my libraries were properly referenced and there didn’t seem to be anything untoward going on. Now I’m at a loss. Just what is going on and how did this happen ‘out of the blue‘?

The Solution

Thanks to Luke Chung & Dan Haught (and their post on their FMS website), the solution is actually pretty straightforward. Luke & Dan give this outline of the problem:

Unfortunately, over time, the part of your Microsoft Access database that stores VBA module code can become bloated, and in some cases, trigger strange errors such as Bad DLL calling convention. As you compile and run code, VBA leaves behind old versions of the code that are no longer valid, but it is not always removed from the database. Database Compact and Repair only addresses the Jet tables in your database, and not the code. That’s why it has no impact when this error arises.

Ah yes! Code bloat! I should have guessed. Checking out the size of the application I’m working on shows that it’s grown from a usual 45MB, to a whopping 240MB even after a ‘Compact and Repair‘ – I’m productive, but not that productive!

What’s needed is a clean up of the code so any old compilations are discarded and we’re left with a clean version of the current VBA. To achieve this:

1. Start Access from the command line (using full path) with the /decompile switch, eg.,: "C:\Program Files\Microsoft Office\Office12\msaccess.exe /decompile"
2. Once Access opens, just go through your usual compile routine (i.e., open any code module and ‘Debug->Compile‘) to clean up the codebase.
3. Finally, Compact and Repair Database...

It works! Once finished, my app size was down to a very respectable 25MB (the smallest I’ve ever seen it).

I was looking for a more in-depth explanation as to what’s going on with the /decompile option, but according to Microsoft’s KB Article ID:819780, the /decompile switch is undocumented (there is certainly no reference to it in the help system or in any of my reference books). If anyone has more information, please let me know.

Additional Resources

You may also find Allen Brown’s discussion on Recovering from Corruption useful as well as Microsoft’s KB Article ID: 279334 (on ‘Repairing a damaged Jet3.5 DB‘).