On 12/01/2022 05:41, Complexity wrote:
> On Friday, 24 December 2021 at 11:12:51 UTC, Rainer Schuetze wrote:
>>
>>
>> On 19/12/2021 17:53, Complexity wrote:
>>> Visual D is crashing Visual Studio 2022 after doing a fresh install of both. This seems to be happening when debugging and adding breakpoints. Did not happen with 2019 so it's either the VisualD release(I think I was using the same) or due to 2022.
>>>
>>> I think simply trying to debug a program will give you the crash.
>>
>> Cannot reproduce here, e.g. on the dmdserver executable. Do you find a crashdump of devenv.exe in c:\Users\name\AppData\CrashDumps?
> 
> No, it doens't produce it, although I had a few crash dumps from 12-30-21 involving the dmd server so maybe it was them.

I forgot that writing the dumps is not enabled by default. Here's a description of the necessary registry entries to enable it:

https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps

The next Visual D installer will enable it for dmdserver.exe, but not for other applications.

> 
> c:\Users\name\AppData\Local\CrashDumps BTW
> 
> It does it both with x64 and x86 although I tried to run it with buggy code(trying to modify some code and had a bug(array accessor) and it crashed in to the debugger but at the entrypoint code with no real information about what happened(but since it was a minor change and an array index error(length instead of length-1 basically) it was obvious where the bug was. So without BP's it does go in to the debugger, more or less but with BP's it crashes VS entirely.
> 
> This is 100% due to upgrading to Visual Studio 2022. I tried another project and I get "cannot launch debbugger on ... hr 89710016".

Are you using the visualdproj format projects or the integration with VC++ projects. If the former, don't use the legacy "Mago" debug engine, it is not supported in a 64-bit environment like VS 2022 (though unfortunately still the default for new projects). Both "Visual Studio" debug engines integrate the Mago debugger extension.

> I also get the error
> Severity    Code    Description    Project    File    Line    Suppression State
> Error        Error: file `"Plotter.py"` cannot be found or not in a path specified with `-J`
> C:\Projects\XXX\XXX.d(125): Path(s) searched (as provided by `-J`):        C:\Projects\XXX\XXX.d    125

This seems unrelated and is likely some option -J missing within the language server.

> 
> Which never occurred before upgrading and seems to not stop the program from working(I have the -J and since it's compiling it is finding the file so this seems to be another bug, maybe related).
> 
> Clearly something is off. I'm pretty sure just a few days ago I was able to run that same project(a different one and a new project I created recently under the new VS) so the issue with launching the debugger maybe because it crashed when I was trying to debug the first project and now it can't launch.
> 
> I'll reboot and try again later. (The reason I say it must have worked is because I had a BP set in the project and don't remember it not working at all)
> 
> So maybe it is an issue with debug information in projects created in previous versions of VS that are not translating debug information correctly to newer projects?
> 
> If you tried it on a fresh project maybe open up an old one and see. (although I do think that the project I used was old but I heavily modified it)
> 
> Almost surely some type of memory access issue given the nature of the crash.

Cannot reproduce with some sample projects, e.g. the Visual D istself or the D compiler. I suspect it depends on the variables being shown in the Locals/Auto Window.

> 
> What happens when I place a breakpoint then run the program it does show the code and the yellow arrow on top of the red BP disk and then it shows the crash dialog about "The instruction at ... references memory at .... The memory could not be written.".
> 
> If I try to debug it then it opens up a new VS with the devenv.exe but nothing really is going on and then if I click start debugging it will run VS. If I open up the project then it says an exception is thrown with "Exception thrown at .... (comctl32.dll) in devenv.exe: 0xC00000005: Access violation writing location ....
> 
> It also says comctl32.pdb not loaded but not sure if that has anything to do with it.
> 
> Does any of this make any sense? Maybe the comctl32.dll is corrupted or versioned wrong or something?

Hard to say without a full stack trace or dump. Missing symbols for the last release, please retry with the next one.