VBA crashes without magical Stops when using Windows Server 2012

Question

I have an XLSM file with VBA, made in Excel 2010 on Windows 7 Pro and it works fine there, but running the same file in Windows Server 2012, it makes Excel 2010 there crash with a generic error message

"Microsoft Excel has stopped working".

But it gets weirder ...

What I tried so far:

• Verified Excel's References are the same between computers and none are marked Missing.

• Verified no database calls -- There are multiple workbooks (one XLSM, a couple of XLSX) and a ton of code, but each project is static and self-contained.

• Used programmatic Stop a zillion times. I'll explain.

I used Stop to find out where code execution works until and where it crashes before, over and over, commenting out stops that worked and didn't, adding new stops, saving, until I narrowed down the exact line of code that makes it crash.

It crashed on that line in break mode, then it didn't, then it didn't crash on that line in run mode. Magically, without altering that line at all, those changes occurred. Only thing I altered was putting Stop before and after, then commenting out the Stops.

Well, obviously I must have accidentally added or removed code other than Stops which caused the offending line to begin executing normally. Code execution went on and crashed at a later point, so again I painstakingly narrowed it down to one line, and again, it magically started executing that line correctly and ran all the way to the end. Now there are no crashes, just because of adding and commenting Stop. Subsequent runs are also fine. A backup copy of original still crashes Excel.

Albeit mysteriously, that would solve the problem, except...

There are a ton of similar XLSM files and their static project folders on Windows Server, each different, and I can't do this for every one even if it did make any sense how the ghosts are being exorcised.

So I'm wondering, is there something I can do with VBA so that it doesn't encounter the issue?

What I tried so far for that:

• Added and commented out Stop at a few arbitrary locations (not spending the hour to narrow down the exact line of code).

• Added a new empty class module.

• Compiled.

None of that stopped it crashing. It's as if my two eyeballs focusing on the offending line is the only solution, but that just makes no sense.

Designed on...

Windows 7 Professional Service Pack 1 64-bit Microsoft Office Professional Plus 2010 Excel version: 14.0.7192.5000 (32-bit)

Problems on...

Windows Server 2012 Standard Microsoft Office Standard 2010 Excel version 14.0.7128.5000 (32-bit)

Answer 1

I've run into this a number of times now on the same server, and importantly, I've run into the lack of it several times on another server, so this definitely seems to fit into the known concept that servers running MS Excel are "temperamental".

Solution:

1. Add any character to any line in a certain arbitrary function.
2. Click on any other line in that same function. (If you skip this step, this solution will fail and the problem will persist unchanged.)
3. Remove the character you added.
4. Repeat that process with each other arbitrary function that needs it.

How to know if a function needs it? It's painstaking and error-prone to figure it out, but in my case I could go through my main Sub and step over until it crashes. Then I could restart Excel, go into that function and repeat the stepping over and crashing, going deeper into functions called by the current function each time, until the crashing no longer happens within that branch of function calls.

In my case, none of the ghostly errors were in the main Sub, only in functions called. It varied, but among many thousands of lines of code, there might be about 5 or 10 ghostly spots.

On a different server with tons of daily use over years, this never happened once, but no one could discover what difference in the servers might prevent it from happening in the first place.