Runtime: System.Diagnostics.DiagnosticSource Causing Error Evaluating the function timedout

[b3hdad]

Description

When I upgrade the package System.Diagnostics.DiagnosticSource from 4.7.1 to 5.0.0, I get the error saying:

Evaluating the function 'System.Diagnostics.TraceInternal.Listeners.get' timedout and needed to be aborted in a unsafe way. This may have corrupted the target process.

I undertand that this page shows how to disable the error but I still thought report it.

Currently I have stopped upgrading this package. Thank you for following up.

Configuration

.Net Framework 4.8
Windows 10
x64

[msftbot[bot]]

Tagging subscribers to this area: @tarekgh, @tommcdon, @pjanotti
See info in area-owners.md if you want to be subscribed.

---

Issue meta data

Issue content:	Description When I upgrade the package System.Diagnostics.DiagnosticSource from 4.7.1 to 5.0.0, I get the error saying: Evaluating the function 'System.Diagnostics.TraceInternal.Listeners.get' timedout and needed to be aborted in a unsafe way. This may have corrupted the target process. I undertand that this page shows how to disable the error but I still thought report it. Currently I have stopped upgrading this package. Thank you for following up. Configuration .Net Framework 4.8 Windows 10 x64
Issue author:	b3hdad
Assignees:	-
Milestone:	-

[b3hdad]

Just wanted to add a bit more to this. I tried step 3, in the workaround link and still get the pop up error when I run the project. Only step 4 seems to prevent this error.

[tarekgh]

CC @noahfalk

[tommcdon]

@b3hdad To investigate help us investigate the expression evaluation timeout, it would be useful if you could send us a dump of the debuggee and debugger when the timeout occurs. These dumps can be automatically collected by enabling a VS specific regkey.

From an admin command prompt (while VS is closed), navigate to the Common7IDE folder under your VS installation and run:

vsregedit set local HKCU AD7Metrics\Engine\{FB0D4648-F776-4980-95F8-BB7F36EBC1EE} FuncEvalAbortLoggingLevel dword 1

This should cause dumps of the debugger and the debuggee to be created in your temp directory, and if you share those dumps with us we can use them to investigate why the timeout is occurring. The dump collection can be disabled by rerunning the same command, but using "dword 0" instead of "dword 1".

One important note: that regkey will only enable dump collection for desktop framework applications. To enable collection for .NET Core applications replace {FB0D4648-F776-4980-95F8-BB7F36EBC1EE} with {2E36F1D4-B23C-435D-AB41-18E608940038}

To send the dumps to us, feel free to open a Visual studio feedback item and then attach the files to it and then send paste a link to the feedback item.

[fcorbeil]

The problem is related to ApplicationInsightsTraceListener. Removing it from the web.config "fixes" the problem...

<configuration>
  <system.diagnostics>
    <trace autoflush="true" indentsize="0">
      <listeners>
        <add name="myAppInsightsListener" type="Microsoft.ApplicationInsights.TraceListener.ApplicationInsightsTraceListener, Microsoft.ApplicationInsights.TraceListener" />
      </listeners>
    </trace>
  </system.diagnostics>
</configuration>

[b3hdad]

@fcorbeil, yes, thank you, that fixed the issue. Will this affect my application insights? Should I put this back later on?

Also thanks to everyone following it up.

[fcorbeil]

@b3hdad, I confirm it'll disable your Application Insights... This is the reason why I added quotation marks on "fixes".

[b3hdad]

@fcorbeil, I see, thank you. Its early morning here on Saturday. Sorry, missed the quotation marks meaning. :)

[panuoksala]

Experiencing same problem when updated .NET Framework 4.6.1 project to use the latest AI nuget. Step #4 in the workaround link works for me too.

[b3hdad]

@panuoksala, will you be able to create the debug information for @tommcdon please? Working in environment subject to some regulations, I may not be able to get permissions soon enough to produce and post what is required.

[shirhatti]

cc @cijothomas

[panuoksala]

What those dump should look like?
Got directories called like this after running the debug dia: Report.5918B293-AF6E-4B98-8028-8529BFF53A6F, 5918b293-af6e-4b98-8028-8529bff53a6f.PackageExtraction, VSTelem and VSTelemOut

[tommcdon]

@panuoksala Whenever an evaluation is aborted a message will shown with the location and name of the dump files.

[karelkrivanek]

@tommcdon > One important note: that regkey will only enable dump collection for desktop framework applications. To enable collection for .NET Core applications replace "FB0D4648-F776-4980-95F8-BB7F36EBC1EE" with "2E36F1D4-B23C-435D-AB41-18E608940038"

Should there be different guid for webforms?

[tommcdon]

@karelkrivanek I believe "FB0D4648-F776-4980-95F8-BB7F36EBC1EE" is the right guid, assuming that webforms is running on .NET Framework 4.x.

[gavinbarron]

When you say Temp directory do you mean the one at C:\Windows\Temp?

I have a .Net 4.7.2 WebApi project (not MVC) that has the same issue and I'm trying to get you some dumps to help diagnose this but can't find the dumps, or they were not created.

[panuoksala]

@panuoksala Whenever an evaluation is aborted a message will shown with the location and name of the dump files.

This is the message:

I'm using Visual Studio 2019 Enterprise, project is .NET Framework 4.6.1 Web API project.

[tiaan-lg]

I experienced the issue when I updated Application insights nuget to 2.16 and it auto-updated this nuget to 5.0.0 as a dependency.

I can replicate the issue, but I'm also not sure where the dump files are located

[gavinbarron]

Not sure who posted and then removed the comment that the dumps are in %temp% but thanks to that person I have submitted a dump through the Visual Studio feedback tool.

[panuoksala]

Not sure who posted and then removed the comment that the dumps are in %temp% but thanks to that person I have submitted a dump through the Visual Studio feedback tool.

It was me. I tried to search for actual filenames, but wasn't able to find them, glad you got it and hopefully we can get this fixed now. I have the same reason for update as @tiaan-lg.

[tommcdon]

Not sure who posted and then removed the comment that the dumps are in %temp% but thanks to that person I have submitted a dump through the Visual Studio feedback tool.

Thanks! Would it be possible to share a link to the community item?

For others commenting on the location of the dump. VS should show a dialog similar to this which contains the path to the dump:

[gavinbarron]

Here's the link: https://developercommunity2.visualstudio.com/t/Upgrading-to-SystemDiagnosticsDiagnost/1270524?port=1025&fsid=248584ff-4927-4143-a95c-37d3cd710d93&entry=myfeedback

FWIW: I didn't get the dialog you're showing here @tommcdon, I got the dialog that @panuoksala shows above.

[tommcdon]

Here's the link: https://developercommunity2.visualstudio.com/t/Upgrading-to-SystemDiagnosticsDiagnost/1270524?port=1025&fsid=248584ff-4927-4143-a95c-37d3cd710d93&entry=myfeedback

FWIW: I didn't get the dialog you're showing here @tommcdon, I got the dialog that @panuoksala shows above.

Thanks for opening the community issue! Unfortunately it doesn't have the dump of the debuggee (iisexpress.exe or dotnet.exe). When setting the reg key, 1) double check that the curly braces are around the guid, 2) vsregedit is running in the right instance of VS (if you have multiple installations), 3) try closing VS first, run vsregedit, then restart VS.

vsregedit set local HKCU AD7Metrics\Engine\{FB0D4648-F776-4980-95F8-BB7F36EBC1EE} FuncEvalAbortLoggingLevel dword 1

Alternatively, if there is a small, reproducible test project, please feel free to send that along.