Visual Studio and Unity Debugger Workflow Error

Visual Studio 17.8.3 throws exceptions when attempting to attach to Unity 2022.3.14f1 LTS. I would report this as a Unity bug, but they will just close it out as non-reproducible. My past experiences trying to get these kinds of bugs resolved results in Unity pointing the finger at Microsoft, and vice-versa. I'm sharing details here in case anyone else encounters this behavior.

Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED) FindActiveProjectCfgName @ ... SolutionBuildManager.cs

9535825--1346125--upload_2023-12-18_7-23-35.png

For others who may be impacted --
- Regenerating csproj files fixed it on one occasion.
- Different Unity versions from the LTS branch manifest the same behavior, i.e. it is not tied to a single release, as far as I can tell.

Hello, I spotted a similar ticket yesterday with the exact same error. This is something I do not reproduce yet on my side, but we are currently investigating.

This seems to be related to the light build feature we have with Unity projects (Indeed we do not need binaries from Visual Studio given Unity is using its own compilation pipeline so we do a special in-memory build to only display error messages).

As a workaround:
- You can set Disable the full build of projects to False in Visual Studio, in Tools/Options/Tools for Unity
- Or you can use Debug / Attach Unity debugger instead of F5/Play, given this will not trigger a compilation.

Any chance you can share your project with me, or at least your generated csproj/sln files ? Perhaps there is something specific to your project.

You can use vstusp[at]microsoft[dot]com

Thank you!

Digging a bit more, it seems that the root issue is a mismatch in your project configurations.

You can double check using a right-click on your solution / Configuration Manager, or inspecting your sln file.

Do you have unloaded projects, or extra projects (non-Unity) in your solution?

Hi there!

Or you can use Debug / Attach Unity debugger instead of F5/Play
This is my typical workflow and I believe it is what I selected in the above scenario.

Any chance you can share your project with me, or at least your generated csproj/sln files
I shared a zip of all csproj files sent to the above email.

it seems that the root issue is a mismatch in your project configurations.
I am using Debug / Any CPU.

Do you have unloaded projects, or extra projects (non-Unity) in your solution?
I am using the csproj files generated by Unity.

I am encountering a separate behavior that may be related. Unity hangs if I start the editor process while a Visual Studio instance is open. See Bug - 2023.3.15f1 LTS - Initial Asset Database Refresh Editor Hang - Unity Forum . The behavior is repeatable and happens often. The workaround of shutting down VS instances before opening Unity resolves the behavior 100% of the time.

I'm using Visual Studio Tools for Unity 17.8.2.

Thank you for the files. Indeed it seems that everything is fine, both in sln and csproj files.

Let's track this issue using this ticket:
Error when using debug in Unity - Developer Community (visualstudio.com)

I'm hitting the same issue, the workaround posted in the microsoft thread does not work for me as the solution build fails
9632069--1368605--upload_2024-2-8_13-2-39.png
I've seen this before but it was intermittent atm i can't get it to go away though, i.e. multiple restarts and rebuilds of the solution file

1 Like

@sailro Any updates you can share? I see this bug, too.

I can understand the frustration when faced with something that doesn't work as expected.

Thanks for your subtle comment about SolutionBuildManager.cs in the feedback ticket but you can imagine that's the first thing we analyzed.

The root cause here is that Visual Studio can't find the active configuration to launch a compilation. This is completely unexpected as, according to our tests, even when trying to delete all configurations from the GUI or from the solution file, Visual Studio is able to recreate a temporary configuration to perform this operation.

That's why, we need more material: provide us with tangible elements, repros, information so that we can reproduce the problem exactly. Otherwise it's impossible for us to correct anything.

This problem clearly seems to be linked to a specific feature of your systems. Maybe your SCM, your antivirus, your filesystem, a third-party extension, etc. We need actionable elements.

Thank you

And as a workaround you can also use Debug / Attach Unity debugger instead of using F5 / Play, as this will attach the debugger without doing a compilation (which is the case for F5/Play).

Thanks for your reply, Sebastien.

I can confirm that when the failure scenario manifests, "Attach to Unity" does not work. Here are some additional details which may be helpful.

  • I'm using Windows 11, 22H2 22621.3007.
  • I'm using the built-in Windows 11 anti-virus.
  • For SCM, I am using GIT.
  • The file system is NTFS.
  • I have optional Visual Studio extensions disabled.

  • Which version of Unity tools are you using? I'm using 17.8.2.0.

  • Which version of Visual Studio are you using? I'm using 17.8.3.

  • Which version of Unity are you testing with? I'm using 2022.3.15f1.

I am most interested in understanding which version of Visual Studio + Unity Tools you are using. Changing versions is easy and it may shed some light on where the behavior exists. If you are using an unreleased or development build of Visual Studio, this is helpful too.

While this is a challenging behavior to recreate, I believe the scenario started after a recent Visual Studio minor version upgrade.

It has not manifest during the previous two days of work. When the behavior manifests, it is consistent and repeatable. I'm wondering if a Visual Studio crash combined with an unterminated process with file locks could result in the above behavior?

Does Visual Studio have a way to capture full stack traces? Or can it generate a minidump when an exception like this is thrown?

Shaun

Re: the work-around not addressing the behavior. This must mean, in my scenario, that Visual Studio thinks it has to recompile, but it can't, correct?

I can confirm I run multiple instances of Visual Studio open with the same project during a typical debugging session.

> I am most interested in understanding which version of Visual Studio + Unity Tools you are using. Changing versions is > easy and it may shed some light on where the behavior exists. If you are using an unreleased or development build of > Visual Studio, this is helpful too.

We tried using the exact same versions. (VS 17.8.3 with VSTU 17.8.2.0). The first thing here is to try to upgrade your VS, given 17.8.6 was released. And 17.9 should comme shortly with an improved VSTU 17.9.0.2.

> For SCM, I am using GIT.

Are you using the built-in Git provider with VS ? Could you try to disable it temporarily to see if you can still repro ? (Tools/Options/Source Control) ?

> It has not manifest during the previous two days of work. When the behavior manifests, it is consistent and repeatable. > I'm wondering if a Visual Studio crash combined with an unterminated process with file locks could result in the above > behavior?

Perhaps, you can use SysInternals Handle utility to double check locks on files:
https://learn.microsoft.com/en-us/sysinternals/downloads/handle

> Does Visual Studio have a way to capture full stack traces? Or can it generate a minidump when an exception like this > is thrown?

You can generate a minidump anytime directly from the task manager. But of course the best is to do it from another VS exactly when it's interesting. For example:
- When you are ready to repro, launch a fresh VS without loading any project.
- Use Debug/Attach to Process to attach to the "faulting" VS. (devenv as process name)
- In Debug/Windows/Exceptions settings, check Common Language Runtime Exception / System.Exception
- Repro in the faulting VS
- You should be able to break in the fresh one, make sure you are on the expected error.
- Use Debug / Save dump as.

The work-around not addressing the behavior. This must mean, in my scenario, that Visual Studio thinks it has to > recompile, but it can't, correct?

This is really strange indeed if you are really using Debug / Attach Unity Debugger window. Because with this one you can attach even if your project is full of typo/errors. You can even attach without a project loaded in fact, as it is completely unrelated. So if you repro even when doing this, clearly something unexpected is interacting.

Are you sure all third party extensions are disabled ? You can use Help/About then "copy info" button to dump loaded assemblies.

I can confirm I run multiple instances of Visual Studio open with the same project during a typical debugging session.

This is interesting. I tried successfully on my side as well. Why are you using several instances on the exact same project ?

Hey Sebastien --

[quote]
Are you using the built-in Git provider with VS ?
[/quote]
Yes. I also have a copy of GitHub Desktop open most of the day.

[quote]
Perhaps, you can use SysInternals Handle utility to double check locks on files:
[/quote]
Great idea and I'll do it the next time it manifests.

I'm happy to save a minidump when it happens. I'll follow the above steps.

I'm using this button to attach:
9634238--1368971--upload_2024-2-9_10-40-39.png

[quote]
Why are you using several instances on the exact same project ?
[/quote]

In a multimonitor setup, if I dock a window (i.e. source code) to a second display, every time I Ctrl + S to save, it causes the window to disappear and reappear. I save reflexively, and it is jarring to have the screen disappear. Two instances resolves this issue. I don't always do this, but it can happen.

The separate scenario is that I have a client component (Unity) and server component, and the server runs as a separate .NET 8 process.

It hasn't happened for a few days -- but as soon as it happens, I feel like these are great steps to provide you additional telemetry.

Note that the workaround is purposely to NOT use that "Attach to Unity" button, but the other command Debug / Attach Unity Debugger, which is not the same thing at all. (just to be sure we are on the same page).

1 Like

Hi Sailro --

The bugged behavior is back. Here is a screen recording showing that alternate Debug / Attach Unity Debugger does not work. The normal "Attach to Unity" workflow fails in the same manner.

https://stellarconquest.blob.core.windows.net/tmp/microsoft/DebuggerFail.mp4 (32MB, 5120x2160).

It appears that having to force quit Visual Studio initiated the behavior. Visual Studio had a soft-lock -- it was running but a pop-up window was locked in the foreground and I couldn't use Visual Studio. I had to force kill the process. Upon relaunching Visual Studio it no longer connects to Unity.

No error messages are displayed. I hope this is diagnostically helpful.

Thanks,
Shaun

In the video, the error is not related to the initial "E_UNEXPECTED" issue we discussed above right? I can even see a "Build completed" in the output window.

In this case it seems the debugger agent died on the Unity side, that's why we cannot connect anymore.

(so it seems to be something completely different)

1 Like

Understood. When the Visual Studio debugger is unable to attach to a process it shows an error message. Since this appears to be an expected behavior, could Visual Studio please show an error message indicating a connection failure?

Do you see something in the Output window, Debug tab. Something like this? :

9656978--1374425--upload_2024-2-21_18-46-59.png

Perhaps we are in a case where we can connect, but we cannot converse with the -dead- Unity debug agent.

Thank you for the response. I am fairly certain it did not show this error message for this scenario. I'll reconfirm the next time it happens.

FWIW, Visual Studio locked up a second time and after force killing the process, the behavior manifest again. It appears to be repeatable by force killing the Visual Studio process.