anti-Heisenbug when using sdbg

I have a little application that I have used for some years for testing desktop scanners. The application is written using FTN95 v4.91, but the actual scanner control is done by calls to a third party library, which in turn interfaces with the scanner driver software.

I got a new scanner on Friday and found that the application runs fine in release mode, but under control of sdbg, either with or without Plato, the program terminates abnormally with exception 0xc000001d.

I can identify the statement that generates the exception condition (a call by my app to the third party library I mentioned), but the various logging tools at my disposal to drill further into what goes on behind the call produce no useful information. I can't even get a record of the exception having been generated.

I did a bit of homework on this exception code (via Google and MSDN). It can arise in a bewildering variety of situations, but the following links refer specifically to this problem occurring within a debugger and not without it:

http://support.microsoft.com/kb/835932 http://support.microsoft.com/kb/234620

In summary, it seems to be a situation where an exception is generated in a code module but not handled by that code module, causing the debugger to barf. Since I have tested a number of scanners over the years and this new one is the first that has ever caused this problem, it seems likely that it is the scanner software that is responsible. I think 😕

I hope this is the most appropriate Silverfrost forum to have posted in; I will be posting similarly to the third party library vendor and the scanner manufacturer.

Can anyone suggest anything I can do to identify the culprit in this situation?

Andy

Replying to myself to ask a more specific question posed by the third party library vendor. I quote:

'But illegal instruction is a little odd... Andy, are you using Fortran? Can you tell the debugger to continue when it reports this exception? My MS Visual C++ debugger lets me do that on an exception, and it then allows the exception handling in the application to catch and handle the exception. In other words, my debugger pops up with exceptions sometimes that are actually normal and expected, and if I tell the program to continue, some other part of the code catches and handles the exception.'

So ... is it possible to instruct sdbg to ignore 'exceptional' exceptions? If not, could this be considered for a future release please?

Andy

Hi Andy

It is possible -- and completely undocumented 😃

In sdbg.ini -- which is in your Windows directory you can put a line like this:

IgnoreException-1=e06d7363

Where e06d7363 is the hex representation of the exception code

Administrator Silverfrost Forums

I was hoping that might be the case. I'll try it and see what happens - hopefully not up to and including WW3. Many thanks.

Hmmm. I've tried this out on a few machines now. It works for the exception I originally asked about - c000001d. But having got past that particular hurdle, another exception crops up - e06d7363, strangely enough, exactly the one that you chose for illustrative purposes - and adding another line to sdbg.ini to ask that it also be ignored does not work. Stranger yet, on a different machine, if I add the same line to sdbg.ini, sdbg is happy to ignore this exception as requested.

I appreciate this is an undocumented feature. Is it intended that it should become documented at some point?

That sounds very strange, is there any chance that on the first machine you are seeing some caching of sdbg? As I recall e06d7363 was something Excel was throwing.

Crikey - how could I tell? (I don't understand caching well enough even to interpret the meaning of 'caching of sdbg' 😮ops:)

It seems that this exception is some sort of generic error code related to Microsoft Visual C exception handling, and requires a special sort of 'ignore me' that Microsoft Visual Studio permits (and presumably would be difficult if not impossible to reproduce in sdbg):

http://support.microsoft.com/kb/185294/en-us

Wading further into deep murky waters here ... under certain specific and well-defined circumstances, I am encountering another exception that sdbg does not seem willing to ignore when I ask it to - 0x000006ba (RPC server not available). Now this one is a real Catch 22 because sometimes (I haven't found a pattern yet) the app in question does not behave as expected when run standalone. It does run, and does not generate any errors. The problem is, it doesn't stop running - it goes right on past a loop upper bound as if it wasn't there - but I can't investigate why using sdbg because of this exception :? .

Am I right in inferring that there are some exceptions that I am not at liberty to ask sdbg to ignore? Exceptions that cause unpredictable runtime behaviour if a debugger is not around to intercept them, so to speak?

sdbg can ignore up to 256 different exceptions. I hae looked at the code and its not obvious why it would not ignore the exception. It is difficult to say what the outcome of masking an exception would be -- by their nature they signify something exceptional -- but that does not necessarily mean its dangerous to continue running the program.

Hi,

I just have a similar problem, when I am using a special DLL in the debug mode.

I could ignore the exception by setting:

IgnoreException-0=c000001d

But now I am getting the next problem. The debugger reports:

Privileged Instruction

Does there exist another hidden keyword to ignore this message?

Thanks for any help!

Detlef

Privileged Instruction is usually a sign something quite serious is wrong. Are you sure you don't get it when you run without sdbg?

The special DLL I am using is designed to detect Virtual Machines and uses some tricky features (as far as I know). In the release mode of my progam everything is working.

Detlef

In that case the privileged instruction exception is probably correct. Is there no way of turning that feature off?

Normally this feature is switched on to detect all kind of Virtual Machines. If it is switched off I can work with the debugger.

Detlef