App That Uses SDK BSODs in Delphi 2007 But Works in C#

Question

I'm coding an application that uses a third party SDK (OCXs). I use the SDK in C# and it works just fine. However, I can create the simplest test application with the same objects from the SDK in Delphi 2007 and it compiles ok, but BSODs on the same machine when it gets to a certain point. I've run some other test applications that use the SDK and they operate correctly, so I know the SDK is installed ok and functioning properly.

Other Delphi projects I work on that don't use this specific SDK operate properly.

Any ideas on how to try to fix this problem? Might I need to remove the OCXs that I've installed in Delphi and add them back? How do you do that?

Answer 1

There is a possibility that floating point exceptions cause the problem. Most runtime environments disable floating point exceptions, but with Delphi, they are enabled.

The disable floating point exceptions, use the following code:

Set8087CW($133f);

Note that this will change the behaviour of your own code as well. You will not get any exceptions any more, if there are errors in a floating point calculation, instead the result variable will be set to either NaN, Inf+ or Inf-.

Answer 2

Very unusual problem. Windows NT based OS's are normally very good at containing faults that occur at Ring 3 inside of user applications. Does the SDK in question interact with hardware through kernel level drivers? Also, what information appears on screen when the system BSOD's. Sometimes this is a clue as to the nature of the problem (e.g. Interrupt handler reentrancy problems, faulty hardware, interrupt conflicts). I have seen this type of problem with Dialogic boards on occasion. The problem may also be a kernel level fault that is not driver related.

Without additional details it has hard to do more than speculate as to the cause. I am inclined to think this is not a FPU control word problem, but I could be wrong. FPU control word problems can result in exceptions, but the exception would need to occur in a critical execution context like a driver where it would not be caught and handled by the OS.

FWIW I have seen FPU control word problems in Delphi JNI libraries that crashed the JVM and host application. The fix was to explicitly wrap the call with code to change and restore the control word as suggested by NineBerry. This works provided the application is not multi-threaded.

Answer 3

Just because you can use the SDK fine from other applications doesn't inherently mean that it doesn't have a problem. It may be reacting badly to certain data items or even to items that shouldn't exist--assuming the contents of memory that doesn't formally contain anything.

I'm sure you've run into bugs caused by uninitialized data items that simply get whatever value was in memory, something like this could be going on with the data area in question being passed in. (Say, a padding byte in a record structure...)

Answer 4

It turns out this was caused by Kaspersky antivirus. I tracked it down by running Windbg against the crash dump and it pointed to kl1.dll. After searching around I tracked down this article which identified it as Kaspersky. I disabled Kaspersky and the BSOD no longer occurs.