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?

Also, when I do a search for some things and it returns back the Visual D search, When I double click on an entry it does not take me to the location.

everything checks out in the list but the path is relative "..\Libs\moduleX.d"

I'm thinking that is the reason it doesn't open it because it doesn't turn that in to an absolute path. It's obviously collecting the right info since it's displaying it all correctly but the open file routine when double clicking on an entry is failing to open the file... suggesting it is most likely due to the relative path.

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.

On Thursday, 16 May 2019 at 15:47:20 UTC, Alex wrote:
> Also, when I do a search for some things and it returns back the Visual D search, When I double click on an entry it does not take me to the location.
>
> everything checks out in the list but the path is relative "..\Libs\moduleX.d"
>
> I'm thinking that is the reason it doesn't open it because it doesn't turn that in to an absolute path. It's obviously collecting the right info since it's displaying it all correctly but the open file routine when double clicking on an entry is failing to open the file... suggesting it is most likely due to the relative path.

This may be a bigger bug because I've noticed a lot of times when I do things Visual D simply either ignores.

For example, if I'm stepping through some code using F11 to step in to and I have function that uses another function like:

if (foo(bar())

I will step in to bar but afterwards not in to foo.

If I do a go to definition on foo I get 3 possibilities...

One for the interface, one for the class, and one for the derived class.

But clicking on any one of them does not take me anywhere.

It seems there is some bug in the resolving of symbols in visual D. It might be related to these relative paths.

I think we already talked about this in some way and there was some issues with how D resolved paths and it solved some other issue. It might be a pattern that Visual D uses based on the old code. I don't remember the details though.

I code is too complex to upload and dustmiting it doesn't work.

D:\dmd2\windows\bin\dustmite --strip-comments --split *.bat:lines D:\.dustmite "build.dustmite.bat 2>&1 | find \"Internal error\""
Suspicious file found: D:\.dustmite\build.dustmite.bat
You should use a clean copy of the source tree.
If it was your intention to include this file in the file-set to be reduced,
re-run dustmite with the --force option.

Not sure why it is using .dustmite in the root directory. It used to do it in the project directory.

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.

LDC uses (slightly modified) C++ exceptions, so debugger support for
these is better.

On 16/05/2019 17:47, Alex wrote:
> Also, when I do a search for some things and it returns back the Visual D search, When I double click on an entry it does not take me to the location.
> 
> everything checks out in the list but the path is relative "..\Libs\moduleX.d"
> 
> I'm thinking that is the reason it doesn't open it because it doesn't turn that in to an absolute path. It's obviously collecting the right info since it's displaying it all correctly but the open file routine when double clicking on an entry is failing to open the file... suggesting it is most likely due to the relative path.
> 
> 

Do you mean the "Search File/Symbol" from the Visual D menu? And your
project contains files that are outside the folder with the project
file? Seems to work here with a simple test. What project type do you use?

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.

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?

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.

On Friday, 17 May 2019 at 07:40:32 UTC, Rainer Schuetze wrote:
>
>
> On 16/05/2019 17:47, Alex wrote:
>> Also, when I do a search for some things and it returns back the Visual D search, When I double click on an entry it does not take me to the location.
>> 
>> everything checks out in the list but the path is relative "..\Libs\moduleX.d"
>> 
>> I'm thinking that is the reason it doesn't open it because it doesn't turn that in to an absolute path. It's obviously collecting the right info since it's displaying it all correctly but the open file routine when double clicking on an entry is failing to open the file... suggesting it is most likely due to the relative path.
>> 
>> 
>
> Do you mean the "Search File/Symbol" from the Visual D menu? And your
> project contains files that are outside the folder with the project
> file? Seems to work here with a simple test. What project type do you use?

When I use "Go to definition"[right mouse button on a function id, say] it pops up the same dialog from Search File/Symbol if there are multiple matches or it see's an ambiguity(I've seen it pop up 0 and 1). Sometimes it takes me to the definition, sometimes it pops up the dialog, sometimes it does nothing.

I'm using standard D project(not the C/C++/D).

I have a hard link in the project dir which points to other files. The hard link is dragged in to the project.

..\Libs

SolutionDir\ProjectDir
SolutionDir\Libs

Hence ..\Libs goes down from the Project Dir and goes in to the Libs dir(which is a hard link to Libs somewhere else but it shouldn't matter). The search that pops up tends to use ..\Libs because that seems to be where it has the most trouble but also because I use oop a lot in Libs.

This actually happens for a lot of symbols that exist in an interface and a class.

It seems the "search" is finding the symbol in the interface and the symbol in the class(and derived) but cannot figure out which one to go to. It shows all 3 but then I can't double click any one to open up the file and go to that line.

i.e., we know it is finding the right stuff but it's just not opening the file when clicked. So this is almost surely a path issue.

Again, we already had an issue like this because of path's not being properly handled in D. (or maybe it was just a problem I had, but there is something were with std.path and relative paths).

Also, There are two options:

1.Go to definition
2 Go to declaration

they both do the same thing it seems.

I don't mind the dialog popping up but if there are 0, 1, or 2 matches it seems it could avoid popping up the dialog in most of these cases. Ideally it would determine which is the actual call being made and choose that one.

What I mean is that if I have something like

interface X { foo }
class Y : X { foo }
class Z : T { foo }

and I'm calling Y.foo(if it is clear) then it takes me to class Y. From there I could use goto definition again it would jump up higher in the chain and take me to X's foo.

Basically work up the hierarchy from the lowest to the highest. This might not be good for large chains though but if it's 2(just a class and interface) then it might be best to have go to declaration use the interface and go to definition go to the class.

Not a huge deal here as long as the search did work as it's just a click away.

Maybe a better way to do all this would be to show the hierarchy in the search(as a tree) and then that would be far more informative.

e.g.,

X.foo ..\Libs\mod.d 43
   Y.foo ..\Libs\mod.d 55
        Z.foo ..\Libs\modZ.d 22
   F.foo ..\Libs\foo.d 4444
Q.bar
   ...
     ...


(just determine the hierarchy and use tabs for inheritance level and maybe marking them as interface, class, abstract class, struct, etc so it's easier to tell without having to open the file).

Anyways, not a huge deal since I could get by without that stuff if I could just get the search to work in the first place...

But my feeling is this issue also is related to many of the other problems I experience such as when debugging and I can't step in to a function since it's not seeing the source code.

They all seem to happen for code that is in ..\Lib but not absolutely specified files.

One of the problems is that when VD can't seem to find the file it does't report anything such as an error message saying the file is not found.

Also, I had this issue with std.stdio; I was trying to jump to stdout.

import std.stdio;
stdout.close();

"go to definition" on stdout failed with "no definition found for stdout".

but "go to definition" on std.stdio worked fine and opened up std.stdio which I then could search for stdout.

	import std.stdio;
	stdout.open("CON", "w");
	stderr.open("CON", "w");

It would be nice if the "no definition found for ..." was more informative such as giving the files it is trying to look for. (such as a popup window listing all them in a text window or in the output window)

Without knowing why stuff fails it's hard to figure out why stuff fails ;/

Thanks again!