Visual Studio quits after loading project

[Universal-Invariant]

Been happening for a few months or so. I haven't been using D much so I can't say precisely when but I noticed it started a while back. Maybe with vs 1.40.

If I reinstall visual d it loads the project but then fails the next time or maybe the next computer restart.

e.g., I just tried to open the project. I VS closed right after. I went ahead and installed visual d 1.40 beta 2(tried non-beta before) and reopened it and it opens. Closed visual studio out and tried to reopen and it fails.

From previous experience of trying to open it several times and it not working until I reinstalled visual d suggests this is either some corruption issue(unlikely but who knows) or some weird issue with visual studio where maybe some setting gets set but is causing vs to crash.

Any ideas?

[rainers]

Is this specific to the project or does it happen with a new project, too?

Are you using the custom visualdproj-projects, or the VC project integration?

What version of VS are you using, i.e. the number shown in the about screen (latest is 17.14.2). BTW: MS just fixed loading projects using UNC paths. Is that's what you're doing?

You can let VS create a log file with

devenv /Log %CD%\NameOfLogFile.xml

Maybe there is a hint in there what's going wrong.

[Universal-Invariant]

It is with every project. This is not happen before. Many of these are old projects that have worked and most have had zero project changes(just code changes).

The last entry in the log file:

 <entry>
    <record>410</record>
    <time>2025/05/27 22:36:22.126</time>
    <type>Error</type>
    <source>VisualStudio</source>
    <description>No InprocServer32 registered for package [Visual D]</description>
    <guid>{002A2DE9-8BB6-484D-987F-7E4AD4084715}</guid>
    <hr>0x80070008</hr>
    <path>C:\Program Files (x86)\VisualD\x64\visuald.dll</path>
  </entry>
</activity>

Looks like the "package" is being unregistered for some reason? Maybe something wrong with the registry? Again, works fine when I install visual D the first time so something is not persisting or being overwritten or corrupt?

[Universal-Invariant]

I went ahead and tried versions all the way back to 1.20 and they all do this. This is likely some issue with visual studio which has broken all versions since I'm pretty sure at least one has worked in the past.

Microsoft Visual Studio Enterprise 2022 (64-bit) - Current
Version 17.10.4

I can't think of anything that I did that might have ruined it except installed the intel compiler trying to mess with the GPU for AI. nothing directly related with visualD but messing with env and such.

Even if I go to help and about it will crash. Seems like it crashes any time trying to access the dll. I wonder if some BS windows security feature could be replacing the dll with junk or possibly a virus? (as far as I know I have no virus and I'd expect it to have issues with other apps)

I tried to manually copy over the install files but that did nothing so this makes me think it is some configuration issue where the installer writes information(possibly to registry) and then Visual Studio tramples on it but it is a guess. I'm going to update visual studio and see if that helps at all.

[rainers]

The log suggests loading the package just fails, but If it crashes, you might find dumps of devenv.exe in %AppData%\Local\CrashDumps. If not, you might have to enable them, see https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps. If available please upload the dump.

Error 0x80070008 is said to mean "Not enough memory resources are available to process this command.", but I doubt this is the actual problem. Maybe the system event viewer also shows some information why the DLL won't load.

Does the file "C:\Program Files (x86)\VisualD\x64\visuald.dll" still exist? Maybe it is moved to quarantine by some anti-virus software. Some other components have been falsely flagged as infected, recently, see for example #298.

[Universal-Invariant]

"Top bug fixes | From the community
Fixed an issue where VS will crash if opening a Solution containing C++ projects via a UNC path.
""

10GB download, I'll install that. Looks like it might be related(just noticed after I checked out the what's new for the previous 10GB update (this is 17.14.3 fix and it says I'm on 17.13.7. I don't have any UNC paths in the project as far as I know but we'll see.

In any case(wrote before I saw this in what's new and started the upgrade process):

The event log shows:

Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 00007FFDEE503FBA

and then

Faulting application name: devenv.exe, version: 17.13.36105.23, time stamp: 0x68193816
Faulting module name: ntdll.dll, version: 10.0.22621.5124, time stamp: 0x82bfa2b9
Exception code: 0xc0000005
Fault offset: 0x0000000000033fba
Faulting process id: 0x0xCE8C
Faulting application start time: 0x0x1DBD34A05FDF676
Faulting application path: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 075514dc-27e6-40cf-a101-f4d49cfc08d9
Faulting package full name:
Faulting package-relative application ID:

I updated visual studio and still doing it. Note that this is only doing it to d projects. why .net is crashing is beyond me since it shouldn't have anything to do with D?

[Universal-Invariant]

Ok, it didn't work either. I was able to load a project after install, thought it worked, tried again and failed.

[rainers]

Sorry to hear that it is still not working. I suspect it is the caller that makes ntdll crash, so a call stack would help. Any chance to get a crash dump?

Alternatively, you could also attach the debugger of another instance of VS to devenv.exe (using the native debug engine). There might be other unrelated non-critical exceptions, so continue execution until the exception with code 0xc00000005 appears. If visuald.dll shows on the call stack, I can also provide debug symbols for the specific version.