Recently two users of our software from the same company started experiencing random closures (no error messages, crash dialogs, quit dialogs etc). We were able to isolate what the two systems had in common down to a particular piece of software (a mobile broadband device manager). When this software is running our software randomly closes within a ~2 minute time frame. If we exit the broadband manager our software runs indefinitely without issue.
I can think of no reason why there would be any interaction between our software and theirs. The network is not accessed by our software and the broadband modem isn’t even plugged in in any case.
We provided a work around for the customer (run our software as Administrator or exit the mobile broadband manager before running our software) but we want to resolve the problem so they don’t need to worry about doing either of these things.
I attached a remote debugger to our software but I wasn’t quite sure where to look to investigate exactly how our software is dying. Debugging just ends with exit code 0 when our process is ended.
My question is, how can I investigate how/why a Win32 process is being killed and what can I do to prevent it from happening?
Edit: I opened the broadband manager and the DLLs it uses in a hex editor and there references to an executable with the exact same name as ours. So I guess that’s the link. Renaming our executable fixes the problem for our users but not, unfortunately, the stupidity of the Sprint SmartView.
Edit: To help the rare other developer this hits: If your executable is named phoenix.exe and your end users are running Sprint SmartView, that’s why your program is randomly dying. Renaming your executable will resolve this (or spend several months of your life trying to figure out who to notify at Sprint to get this truly resolved). The file that mentions phoenix.exe specifically is WwanCoreSdk.dll.
If your app is 32 bit, try to check out WinAPIOverride32. It will show you all syscalls done by program, so If you are able to time killing your program correctly in log from mentioned manager, it should make it easier to explain why it is happening.