Since you can't resolve the problem until that's done, you have two choices - wait or start changing code.
Not really, the code has been in production for 2.5 years, the problem has to be something that has changed from the shipping version.

This is a clear case of "We don't have the time to do it right the first time, but we have the time to do it over and over, trying everything short of doing it right."
The OCX code (a full blown mapping application) was bought in, not done in house. It represents 3-5 man years of effort, fixing that is no trivial thing.

And, with no error trapping, you'll never find the error. You could waste a few months guessing, or you could spend a few weeks finding and fixing the errors.
Again not always true, you have to be pragmatic about these things, it has been running on client sites for years. Admittedly the code improvement should have started a long time ago but it is always hard to justify fixing things that work and the next version had to be completed in the next 2 years.

Happily this issue has allowed me to make the case more strongly and I have a developer working on injecting my error handlers and tidying up the code. It will take a month or three.

Having proper error trapping everywhere would not have helped in this case as the problem was discovered to be a memory leak in an unrelated 3rd party control that was included 2+ years ago. FarPoint Spread 7.00.43 which appears to have a memory leak causing this issue. Once patched to 7.00.47 the problem was resolved.