>Geo,
>
>>Nope! The error is occurring in DisconnectServers which is called from QueryUnload.
>
>So maybe it hops back into the original QueryUnload after the DisconnectServers finishes calling Destroy, and that gets logged again?

I doubt it, David. DisconnectServers only calls a method to un-map drives that have been mapped by the application. It's an SDI app, BTW.

Naturally, QueryUnload() is called whenever a user attempts to close the program, either via the close box or the Exit command button. The Exit command button calls QueryUnload() to see if the program is processing, if not, then ThisForm.Release is called. Naturally, the QueryUnload does the usual stuff to keep the application from terminating if processing is still occuring.

About the only thing that comes to mind, is hard to test for. The error log has a date/time stamp. This error occurred on 8/11, but not since, and occurred 4 times within 8 seconds. Each was exactly the same in terms of the call stack. Since there are multiple users it could have been 4 different users, but I kind of think that's a remote possibility (makes note to add a user name field to the error table). The possibility that came to mind was based on the time that it occurred (4:58:51 PM). I'm thinking that the app may still have been running when the user turned off their computer. I haven't tested that scenario.

If it did cause it, something about the application recieving the WM_QUERYENDSESSION or WM_ENDSESSION message that's generated, in conjunction with it being an SDI application.