Visual D Privileged instruction

[Alex]

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?