On 17/05/2019 11:18, Alex wrote:
> On Friday, 17 May 2019 at 07:42:32 UTC, Rainer Schuetze wrote:
>>
>>
>> On 17/05/2019 03:10, Alex wrote:
>>> After upgrading to VS2019, dragging a variable from the autos, locals, or watches copies the whole line, including any junk rather than the address or the name. In 2017 one could drag and it would just copy the address.
>>>
>>
>> Yeah, I noticed this too, but wasn't sure whether it was related to the VS update or to something else. Thanks for clarifying.
> 
> It would be nice too it would use the variable name since one can set the auto button to refresh it... if that works in some way. May be better to make it optional. This way I don't have to keep refreshing the ptr value every re-run to see the same memory or manually copy the variable name.
> 

If you enter the expression manually, it is shown with "auto" enabled and it works.

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@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.