Visual D Privileged instruction

[Rainer Schuetze]

On 17/05/2019 11:16, Alex wrote:
> On Friday, 17 May 2019 at 07:33:57 UTC, Rainer Schuetze wrote:
>>
>>
>> On 16/05/2019 17:28, Alex wrote:
>>> 0xC0000096: Privileged instruction.
>>>
>>> This happens when I run an app that throws an error inside visual D.
>>> When I run it on it's own I get the correct error.
>>>
>>> std.file.FileException at std\file.d(449): data.xml: The system cannot find
>>> the file specified.
>>> ----------------
>>> 0x00007FF61625E4B9 in @trusted bool
>>> std.file.cenforce!(bool).cenforce(bool, scope const(char)[], scope
>>> const(wchar)*, immutable(char)[], ulong)
>>> 0x00007FF61624ECB2 in @safe void[] std.file.readImpl(scope
>>> const(char)[], scope const(wchar)*, ulong)
>>> 0x00007FF615F8EC0E in std.file.read!string.read at
>>> X:\dmd2\windows\bin\..\..\src\phobos\std\file.d(313)
>>> 0x00007FF615F8B083 in D main at main.d(133)
>>>
>>> The problem is that I have to open up a console and run the program
>>> in it to see this error.
>>>
>>> This only happens with x64 and happens with every single throwing error.
>>>
>>> Is there a bug in the code that handles exceptions for x64 that is
>>> causing the privileged instruction error?
>>
>> dmd doesn't use a standard exception handling for x64, but implements
>> a generic version derived from older posix implementations.
>>
>> Usually all exceptions or errors are handled by the runtime showing
>> the stack trace. But when running in a debugger, unhandled exceptions
>> are not caught by the runtime but the privileged instruction is
>> executed. This allows analyzing the code at the location of the throw.
>> The debugger should show you the same callstack as the trace above.
>>
> 
> The call stack does not show the actual error message though. So I have
> no idea what is actually causing the crash.
> 
> The error string clearly exists somewhere because it is shown in the
> stack trace on the error when run outside the debugger.
> 
> Can Visual D simply add to the error message the "last line" in the call
> stack(whatever line that would show the error string) or figure out
> where it's at and show it.
> 
> Basically some information is better than none. Sometimes the error is
> not really matched up with the line that the debugger takes one to so
> it's difficult to diagnose since privileged instruction is completely
> uninformative.
> 
> or maybe it could just print the full stacktrace to the output window on
> an exception/error?
> 

The mago debug engine (that you can select with visualdproj projects)
can actually show the exception type and its message (probably 32-bit
only), but I have no idea yet how to get this into the (preferred)
debugger extension.