STATUS_ACCESS_VIOLATION in coreclr.dll version 9.0.24.52809 #109981
Comments
dotnet-issue-labeler
bot
added
the
needs-area-label
dotnet-policy-service
bot
added
the
untriaged
|
I am having the same issue; Works ok with .NET8, converted to .NET9 and then receive the following error below; Faulting application name: dotnet.exe, version: 9.0.24.52809, time stamp: 0x67204d77 |
This is a different issue. For example, it has different Exception Code. You may want to open a new issue on it.
Do you see more detailed error message on the console or in the event log (open Event Viewer application that comes with Windows to and go to Windows Logs / Application)? Here is an example what the more detailed error looks like:
|
|
This is in my event viewer: |
This looks like an issue in your application code. What does the code in Program.cs around line 71 look like? Where is the null value coming from? |
|
The null is from trying to use this...dotnet a.dll -ENVIRONMENT=dev
|
Could you please elaborate? I do not see how this explains where the null is coming from. |
|
Hi, |
|
@rsankardayal It is unlikely that the problem that you are experiencing is going to be fixed in .NET 9 unless we get to the bottom of the issue. |
|
Faulting application name: hcmanagement.exe, version: 2.1.0.10, time: 0x66f10000 Faulting module name: coreclr.dll, version: 9.0.24.52809, time: 0x672049fc Exception code: 0xc0000602 Fault offset: 0x000000000032a356 Faulting process ID: 0x28c8 Faulting application start time: 0x01db3cb3386587e4 Faulting application path: C:\Qingshan Changyuan Software\Qingshan Changyuan Cost System\hcmanagement.exe Faulting module path: C:\Program Files\dotnet\shared\Microsoft. NETCore.App\9.0.0\coreclr.dll Report ID: 7596c246-d81b-4054-9e57-de74abc50f1d Faulting package full name: |
@shuijianfeng This exception code is not STATUS_ACCESS_VIOLATION that this issue is about. Please open a new issue on it and include more detailed error message that you should be able to find in on the console or in the event log. |
jkotas
added
area-VM-coreclr
needs-author-action
|
This issue is marked as needs-author-action. |
dotnet-policy-service
bot
removed
the
needs-author-action
|
Do you see more detailed error message on the console or in the event log (open Event Viewer application that comes with Windows to and go to Windows Logs / Application)? (#109981 (comment)) |
|
My understanding is that Microsoft staff have access to the data uploaded by Windows Error Reporting - including dmp files etc. Is this not the case? The WER event does indicate files were uploaded. There was no console output. There is more in the event log which I have pasted below. Sorry I omitted this - it was because I thought you'd have access based on the report Id. |
The system applies a lot of filters and it does not keep much information for one-off crashes. All I can see that there were two crashes in internalweb.exe in November, but no additional details.
This says that there was unhandled exception in your app code. Are you able to find the exception type, message, and the app code that throws it? |
|
The top line of the call stack:
at InternalWeb.Controllers.SSEClientController+<ClientConnect>d__26.MoveNext()
means it was in the ClientConnect function (I presume), and MoveNext()
tells me the state machine has just returned from an await - is that right?
All the code in ClientConnect() where an await occurs is within a try/catch
block. No exceptions were caught that resulted in a log entry being written.
The server runs as a Windows Service, so I couldn't see any console output,
and I rely on Serilog logging to a file - no entries were made.
The output I posted was one of 3 Windows Events written for each of the two
crashes: there was an Information Event from WER, and 2 Error Events, one
from ".NET Runtime" (that's the info I posted recently), and the other is
from "Application Error", which I used when I opened this issue - see below.
This indicates (I believe) that the fault was in coreclr.dll?
My code is an ASP controller, and there are no unsafe contexts present (in
my code), so I presume that means I couldn't have directly caused the
0xc0000005 ?
I just realised I do have the option to stop my code running as a service,
and to run it from a command prompt - that way I could capture any console
output.
I'll do that.
Faulting application name: internalweb.exe, version: 2.6.0.0, time stamp:
0x67200000
Faulting module name: coreclr.dll, version: 9.0.24.52809, time stamp:
0x672049fc
Exception code: 0xc0000005
Fault offset: 0x00000000002eea8b
Faulting process id: 0x6adc
Faulting application start time: 0x01db3659d2f58280
Faulting application path: c:\src\server\publishnet\internalweb.exe
Faulting module path: C:\src\server\publishnet\coreclr.dll
Report Id: 324f8194-84f9-4ced-b429-27044b78e4d5
Faulting package full name:
Faulting package-relative application ID:
…On Wed, 27 Nov 2024 at 09:14, Jan Kotas ***@***.***> wrote:
My understanding is that Microsoft staff have access to the data uploaded
by Windows Error Reporting - including dmp files etc
The system applies a lot of filters and it does not keep much information
for one-off crashes. All I can see that there were two crashes in
internalweb.exe in November, but no additional details.
InternalWeb.Controllers.SSEClientController+d__26.MoveNext
This says that there was unhandled exception in your app code. Are you
able to find the exception type, message, and the app code that throws it?
—
Reply to this email directly, view it on GitHub
<#109981 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APLVAYXUM6KRY5OBJUVM4FD2CTJBJAVCNFSM6AAAAABSDBODSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBRHAZTCOJZHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
This fails regularly for me, and I have captured a mini dump from the crash. |
|
You can open an issue at https://developercommunity.visualstudio.com/, attach the dump to it and share the link to it here. https://developercommunity.visualstudio.com allows attaching larger files and it has better privacy controls. |
|
Please see: VS report with attached dmp |
|
That you for sharing the dump. The crash is caused by tiered compilation (cc @dotnet/jit-contrib): If possible, could you please do two more things - it would help us with diagnosing the problem faster:
Thank you! |
jkotas
added
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
Ok, I've set DOTNET_DbgMiniDumpType=4 as requested and the server is running. |
|
Sorry, it took an extra night to capture the dump. Anyway, the full dump can be found attached here: |
|
I've installed 17.12.3 and here are the steps to reproduce.
|
That's not the same issue. That looks like you're trying to bind to port 443 without permission. Try running VS as admin. |
|
@rstutton Thank you for collecting another dump! The latest dump confirms that the crash always occurs when the JIT is compiling the same method ( Could you please collect a dump using procdump tool using following steps:
When the server crashes, procdump should produce dump in the current directory. This crash dump should have better information about the root cause. |
|
Hi @rstutton, Agreed not the same issue, where would I submit my issue.
From what I can see it has something to do with the project name length, any project name over 15 char length seems to fail.
|
You can submit it either to dotnet/runtime or dotnet/aspnetcore repos. We route issues as necessary. |
|
A new dump (produced by procdump) has been uploaded: |
|
Stacktrace of the crash: @dotnet/jit-contrib Could you please take it from here? |
jakobbotsch
removed
the
untriaged
|
@rstutton Thanks for the report and for working with us to capture the dumps. It would be very helpful if you could additionally collect a SuperPMI recording of this particular JIT compilation, so that I can figure out how the JIT has gotten into the state that I see in the crash dump. To record it please obtain superpmi-shim-collector.dll (I have attached a copy on the VS report you submitted). Place that file at When you run the application, you should see a .mc file (or potentially multiple .mc files) appear in the folder you specified in FWIW, it is very likely you can get a quicker reproduction of this problem with tiered compilation disabled ( Finally, there should be a workaround for the problem you are hitting by setting |
|
@jakobbotsch I have uploaded the captured mc file to VS report with attached dmp. |
|
@rstutton Thank you! I am able to reproduce the problem locally now using the file you have provided. I'll work on a fix and post back with an update. |
|
Some technical notes: we have a case where |
|
Some more technical notes: The failing case roughly looks like the following EH wise, translated into C#: public static void Foo()
{
try
{
return;
// BeforeTry
try
{
try
{
// InnerInnerTry
}
finally
{
// InnerFinally
}
}
catch (SomeException)
{
// CatchHandler
}
}
catch when (FilterCode) // FilterHandler
{
}
}The JIT has made some late optimizations that allows it to realize that At the same time we still consider All of these flow edges are spurious, meaning that they cannot actually happen at runtime, but we cannot statically make that determination without optimizing out some blocks that induce those spurious flow edges. We would normally do that, but in this case we do not because of how late the optimization happened. Now, the real problem happens when we try to compute the dominator of |
dotnet-policy-service
bot
added
the
in-pr
|
I opened #110531 with a fix for the issue. I will backport that fix to .NET 9 servicing after it is merged. The next servicing release won't be until January (at the earliest), but in the meantime the problem can be worked around by setting Thanks a lot for the report and for collecting all the extra information! I will leave this issue open until the servicing release with the fix has been published. |
Description
Faulting application name: internalWeb.exe, version: 2.6.2935.0, time stamp: 0x67200000
Faulting module name: coreclr.dll, version: 9.0.24.52809, time stamp: 0x672049fc
Exception code: 0xc0000005
Fault offset: 0x00000000002eea8b
Faulting process id: 0x649c
Faulting application start time: 0x01db3988d312000b
Faulting application path: C:\Program Files\3DBackup\bin\internalWeb.exe
Faulting module path: C:\Program Files\3DBackup\bin\coreclr.dll
Report Id: 8d1a48a5-e27f-4a5f-acbf-1d40624ed842
Reproduction Steps
This happened 2 nights running before I backed out the migration to .net 9.
I have not isolated the fault.
WER reported the issue and captured data on both occasions:
Report Id: 8d1a48a5-e27f-4a5f-acbf-1d40624ed842
Report Status: 268435456
Hashed bucket: 2e7dfb54d62033d3fc1a7aa712618a8b
Report Id: 324f8194-84f9-4ced-b429-27044b78e4d5
Report Status: 268435456
Hashed bucket: 3700e920166dc8b4904ac6c8801323ea
Expected behavior
Not crashing.
Actual behavior
STATUS_ACCESS_VIOLATION in coreclr.dll crashes the app.
Regression?
Yes. The same code runs fine in .net 8, has been in production, and on customer sites.
Known Workarounds
None.
Configuration
.net sdk 9.0.100
aspnet core.
OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.19045 N/A Build 19045
OS Manufacturer: Microsoft Corporation
OS Configuration: Member Workstation
OS Build Type: Multiprocessor Free
Product ID: 00330-51446-83390-AAOEM
Original Install Date: 27/05/2022, 1:27:58 pm
System Boot Time: 13/11/2024, 9:28:29 pm
System Manufacturer: HP
System Model: HP Z240 Tower Workstation
System Type: x64-based PC
Processor(s): 1 Processor(s) Installed.
[01]: Intel64 Family 6 Model 94 Stepping 3 GenuineIntel ~4001 Mhz
BIOS Version: HP N51 Ver. 01.70, 19/06/2018
Total Physical Memory: 32,553 MB
Other information
No response
The text was updated successfully, but these errors were encountered: