A weird debugging question

I'm 'enhancing a program without the authors consent'. I'm not cracking it, I don't even like it. But there are people who do, and they really want it to talk to a piece of hardware that the Author doesn't want it to talk to (because they have competing hardware).

I got it working in less than a day, but there's a bug. I need to dismiss a connection to the actual hardware driver, and the only way I know I'm done with it is in DLL_PROCESS_DETATCH. I can't dismiss it there, because the unload code needs to do things that can't be done at that time.

Without the bug being fixed, the user has to end-task the executable (which, btw, has a .MOD extension). Very few of the 90+ DLLs have sane extensions. Some have almost pseudo-random extensions. No match for PEiD.

None of the modules are packed, none are convoluted other than what you'd see with a severely over-bloated piece-of-dung software package.

Anyway, I used VTune to find the module I was interested in. It happily pointed to the right spot, bouncing up and down like a loyal puppy-dog. I wrote my replacement DLL in a matter of hours, despite some of the arguments being pointers to structures 100's of bytes long. IDA is wicked stuff.

But I have no way to know before hand that the application is going to terminate. If this was for MY use, I'd just patch the MOD exe to call a new routine in my DLL saying "Hey, were done now". But patching is (nearly) out of the question. (there are a number of builds, I don't want to write a number of patches).

My problem: The 'MOD' program is called by an 'EXE', which goes away. When I try to attach Olly, it kills a thread and becomes catonic. I really need to debug to determine if there is some circumstance I can use to detect the program is about to unload BEFORE I get the DLL_PROCESS_DETATCH.

Any ideas?