0

A little back-story: When testing an installer for our C# (.NET 4.0) software recently, we installed on 7 or 8 different machines with success. But, one of our QA members installed and was able to get the application to consistently crash on his machine.

The first thing our application does - before anything else - is to spawn an external application, wait for it to do its thing, (more on this later) then exit. If we didn't launch the external application, it would prevent the crash on his machine.

The truly odd thing is that the crash happens much later in the main application. Long after the external exe had finished and exited. To verify that it wasn't the external process itself, I had the main app launch notepad instead. When he exited notepad, the application would resume as usual. This ALSO caused the crash. In the end, telling the external application to start up with "Process.UseShellExecute = false" prevented the crash.

//Successful code
Process myProcess = new Process();
myProcess.StartInfo.FileName = "MyProcess.exe";
myProcess.StartInfo.UseShellExecute = false;//Only difference between crashing and non-crashing code
myProcess.Start();
myProcess.WaitForExit();
...
myProcess.Dispose();
myProcess = null;

Other relevant info: The crash always happened on an attempted method call in an imported DLL written in Delphi 5 ages ago. Unfortunately, I don't know much about the inner-workings of this DLL, but the fact that this has only failed on this specific machine makes me think that it's not the issue. The error we got from event viewer was this:

Faulting module name: ntdll.dll, version: 6.1.7601.22436, time stamp: 0x521eaa80 Exception code: 0xc0000374

(0xc0000374 is a heap corruption)

It makes sense to me that the two types of execution would be different, but what could be different about this person's machine that using the Windows Shell would cause a crash?

Danno
  • 53
  • 1
  • 7
  • Heap corruptions have an element of unpredictability about them. It's not uncommon for them to be unrepeatable and intermittent. Sounds to me as though you should address the real problem and fix the heap corruption. `UseShellExecute = false` will just sweep it under the carpet (you hope). Who's to say it won't come back? – David Heffernan Feb 10 '14 at 16:49
  • Frankly speaking I'm not sure it's same issue but I had troubles importing an old C++ Builder DLL. I don't remember details (sorry) but it has something to do with exception flags on CPU that didn't get reset properly. Put `try { throw Exception("Oops."); } catch (Exception) { }` (just once) before you call any imported method from Delphi DLL and try again. – Adriano Repetti Feb 10 '14 at 16:54
  • Just a few thoughts that float to the top of my head...is there anything unusual on the particular QA machine's environment where the failure is occurring? Also, some of the MSDN docs encourage initializing COM when calling ShellExecute (CoInitializeEx) - so if there's something odd on that QA box related to COM, perhaps the Delphi call exposes it (albeit obscurely/indirectly)... – David W Feb 10 '14 at 16:57
  • @Adriano You really ought to have the details before you suggest random suppression of exceptions (which should not pass across DLL boundary anyway). Perhaps you are talking about Borland runtime's preference for unmasking floating point exceptions. Perhaps not. But without details your suggestion is unhelpful at best. – David Heffernan Feb 10 '14 at 16:59
  • @DavidHeffernan maybe that, maybe not. I really can't remember details anyway I'm not suggesting to suppress exceptions wrapping each method call inside a try/catch block with an empty catch (!!!). Just to generate an exception to reset that flags. Once, using exactly that code. If it's his case well, good. If it's not... – Adriano Repetti Feb 10 '14 at 17:12

0 Answers0