AccessViolationException originating from mscorjit

  • Thread starter Thread starter Sune Foldager
  • Start date Start date
S

Sune Foldager

Greetings

We have a (rather large) project at work which consist of almost only managed
C# code, with a little interop-code. Recently, we encountered a strange error
(an AccessViolationException) occurring only in the following setup:

a) Windows Vista 64bit (32bit works fine)
b) Visual Studio 2008 (with or without Service Pack 1)
c) Only when building in release mode
d) Only when starting the program normally; When starting it with the Visual
Studio debugger, the error does not occur. If we attach to it while running
(with VS), the error does occur but VS never catches the produced exception.

The AccessViolationException is catched in our program. The stack trace (we
have pdb files even in release mode) shows one of our methods as originator,
but no line numbers. We think it may be caused in the JITting of that method,
based on the following dump from windbg:


(11bc.7ac): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
mscorjit!LifetimesFindDefOutsideOfTryForOpTryEndPhi+0x14:
000007fe`f0d85fd4 4c8b4818 mov r9,qword ptr [rax+18h] ds:00000000`00000018=????????????????
0:031> g
(11bc.7ac): C++ EH exception - code e06d7363 (first chance)
(11bc.7ac): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
KERNEL32!RaiseException+0x39:
00000000`7730649d 4881c4c8000000 add rsp,0C8h


Originating from mscorjit, it seems. Does anyone know what the cause of this
could be or how we could aid in debugging the problem further?

Sincerly,
Sune Foldager
Edlund A/S
 
Sune Foldager said:
Greetings

We have a (rather large) project at work which consist of almost only
managed C# code, with a little interop-code. Recently, we encountered a
strange error (an AccessViolationException) occurring only in the
following setup:

a) Windows Vista 64bit (32bit works fine)
b) Visual Studio 2008 (with or without Service Pack 1)
c) Only when building in release mode
d) Only when starting the program normally; When starting it with the
Visual Studio debugger, the error does not occur. If we attach to it while
running (with VS), the error does occur but VS never catches the produced
exception.
Click to expand...

As described, it seems to hint at the bug in JIT optimizer. When you start
debugging from VS, JIT optimizations are suppressed regardless of build
type, but they aren't when you attach to an already running process.
The AccessViolationException is catched in our program. The stack trace
(we have pdb files even in release mode) shows one of our methods as
originator, but no line numbers. We think it may be caused in the JITting
of that method, based on the following dump from windbg:
Click to expand...

If your assembly is deployed to GAC, you might have to copy the .pdb over to
your .dll in the GAC to get the line numbers.
Originating from mscorjit, it seems. Does anyone know what the cause of
this could be or how we could aid in debugging the problem further?
Click to expand...

Your best bet is going directly to Microsoft. VS Connect
(https://connect.microsoft.com/VisualStudio/Feedback) is the usual public
channel (and if you post reproducible code there, it also lets other people
validate it and confirm the bug).
 
Hi Sune,

In the VS debugger, you may examine the "Modules" window to find out why
your pdb symbol files are not loaded for your application. If your dll is
deployed into the GAC, then you may meet the problem as Pavel described.
Also, you need to turn-on the first chance exception handling in the
Debug->Exceptions dialog for AccessViolationException so that
AccessViolationException is caught in the VS debugger. As I know, windbg
turns on the first chance handling for access violation exception. That's
why windbg will break successfully for you.

The windbg output in the post is a bit confusing to me. The first output
looks like an Access Violation exception in
mscorjit!LifetimesFindDefOutsideOfTryForOpTryEndPhi(), while the second
output is an Access Violation exception in KERNEL32!RaiseException(). So I
would believe that these two AV exceptions are different ones. I suspect
the first AV exception is unexpected caught by your program code, so it
will not report second chance exception to the windbg after you press "g".

To perform an initial analysis for this issue, can you input the following
commands in the windbg:
1. r (examine all the CPU registers status at the time of the crash)
2. !teb (examine the stack range for the crashing thread)
3. kvn (examine the code path that generates the crash)
4. ~*kvn (examine the stack for all the threads in the application)

You may input these three commands for both these two AV exceptions so that
we can perform the analysis for them both(sure, the first AV exception in
the JIT compiler should be more important). Please paste the command output
here for analysis.

Finally, I agree with Pavel that it would be helpful for you to feedback
this issue through the connect project. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Sune Foldager said:
See the readme.txt file for more information. I hope you will be able to
reproduce given
this information, and I plan to post it to Connect soon as well.
Click to expand...

If you're looking for a quick temporary workaround (assuming that creatively
rearranging code didn't work), consider using MethodImplAttribute with
MethodImplOptions.NoOptimization on the offending method.
 
Hello Pavel,
If you're looking for a quick temporary workaround (assuming that
creatively rearranging code didn't work), consider using
MethodImplAttribute with MethodImplOptions.NoOptimization on the
offending method.
Click to expand...

Thanks, I didn't know about that one. Actually, creatively rearranging does
work, and it's quite easy to get the problem to disappear. For instance,
there is a foreach(var a in b) somewhere, which has a rather large body in
the original, unreduced, code. By simply iterating with foreach, over b,
one time, copying all elements to a fresh List<T>, and then iterating over
that List<T> in the large foreach, the problem disappears :-). There are
many other similar cases.

-- Sune
 
Hi Sune,

Thank you for the sample project.

I have setup a Vista x64 machine with VS2008 SP1 to test this issue; yes, I
can reproduce this AccessViolationException.

I will spend more time on this issue and get back to you ASAP. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Sune,

Sorry for letting you wait, I was out of office yesterday.

Since I can reproduce this consistently, I have filed a bug requst to the
x64 CLR JIT team. Now, the CLR JIT developer has confirmed this as a
problem for x64 JIT and filed it for tracking. Thank you for reporting it.

We believe there are several possible work-arounds that mainly just boil
down to random changes to the method change the register allocation
heuristics. Refactoring the code into smaller methods (the triply-nested
foreach loops would be a good place to start) might help for the same
reason. The sure fire way to work-around is to disable optimizations for
just that methods with the new attribute:
[MethodImpl(MethodImplOptions.NoOptimization)]. I see Pavel has provided
this solution to you :-).

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top