none
AccessViolationException in .NET 4.0 RRS feed

  • Question

  • Hello All,

    In my current application I have a reference to a dll written in c++. Every thing is working fine when I'm debugging the .NET 4.0 winforms application. When I stop debugging and do CTRL F5 or run it straight from the BIN folder, then I get the AccessViolationException . The funny thing is that this was working in .NET 2.0. So I take the same code, put it in a .NET 2.0 application and it works.

    So what do I do..I create a class library in .NET 2.0 and reference it in my .NET 4.0 project. Same result, AccessViolationException

    Can anyone explain me why it's working in debug mode and not outside VS? Does it have something to do with trust?


    Blog: mshelp.be
    Wednesday, April 21, 2010 7:54 PM

Answers

  • Most likely there is a bug in your application which reads/writes memory it shouldn't. It can be caused by native code, or by wrong PInvoke/COM interop.
    The difference between debug and release mode is different allocation strategy and memory usage patterns. Your debug mode version is probably just lucky that it works.

    Attach debugger to the crashed process and get full call stack to find out who is causing the AV. If the AV is from clr.dll, then it is likely a heap corruption (see my reply here in such case).

    -Karel

    • Marked as answer by SamAgain Thursday, May 6, 2010 8:15 AM
    Wednesday, April 21, 2010 8:56 PM
    Moderator
  • It is likely caused by some changes in .NET 4.0. But that doesn't mean that it is a bug in .NET 4.0 (even though it could be).
    For example: Imagine that .NET 4.0 decides to allocate memory from higher addresses (e.g. starting at 0x40000000) than 2.0 did (let's say it allocated at 0x00100000) and you have a bug which always reads memory at constant address 0x001000100. Then you are lucky in 2.0 and it works, because the memory is always allocated. But it will likely fail in 4.0, unless something else allocates the memory there at the same address.

    Without knowing exactly why the AV happens on 4.0 it is hard to say more about it.

    Re: In-proc SxS:
    In-proc SxS will not help in case you want 2 assemblies to work with each other. In-proc SxS is good for plugins and extensions, where the 2 CLR versions communicate through COM interfaces (which I guess is not this case).

    -Karel

    • Marked as answer by SamAgain Thursday, May 6, 2010 8:16 AM
    Thursday, April 22, 2010 12:40 AM
    Moderator
  • Spoofer, the answer is still the same: You have to find out what is causing the problem in your application to get an answer. There is no magic "Behave like 2.0" switch. Such thing is truly impossible to implement (from the reasons stated above). The only general advice would be to stay on 2.0 (if you don't want to debug it, or if you cannot make the vendor fix the library which is causing the issue - if it is the library causing the issue).

    Gertwor, there can be more than one million different reasons why your application doesn't work on 4.0. What is the chance that someone else will hit exactly the same issue?
    Try to debug the problem - get full call stack and look at it/post it here. If that's not helpful, try to isolate the problem into a small repro. That's IMO faster than just waiting for a chance to happen.
    BTW: Compiler switches are IMO not likely the reason of your trouble (AFAIK they almost never are).

    -Karel

    • Marked as answer by SamAgain Thursday, May 6, 2010 8:16 AM
    Thursday, April 22, 2010 4:22 PM
    Moderator
  • The only alternative is to debug the assembly code - that's rather hard.

    Yes, in-proc SxS could help you with this. Add a COM interface between your library and your application. Your library then can then run on 2.0 while your application can run on 4.0 and they can both communicate via that COM interface.

    -Karel

    • Marked as answer by SamAgain Thursday, May 6, 2010 8:16 AM
    Thursday, April 22, 2010 6:26 PM
    Moderator

All replies

  • Most likely there is a bug in your application which reads/writes memory it shouldn't. It can be caused by native code, or by wrong PInvoke/COM interop.
    The difference between debug and release mode is different allocation strategy and memory usage patterns. Your debug mode version is probably just lucky that it works.

    Attach debugger to the crashed process and get full call stack to find out who is causing the AV. If the AV is from clr.dll, then it is likely a heap corruption (see my reply here in such case).

    -Karel

    • Marked as answer by SamAgain Thursday, May 6, 2010 8:15 AM
    Wednesday, April 21, 2010 8:56 PM
    Moderator
  • THe strange thing is that exactly the same implementation / code is working in .NET 2.0. Could it be that something changed in .NET 4.0 that could cause this?


    Blog: mshelp.be
    Wednesday, April 21, 2010 9:11 PM
  • This is the exact reason why .NET 4.0 has Side-by-Side. I am not encouraging the fact that you shouldn't fix the bug, but with .NET 4.0 you can essentially have SxS with in a process.

    To answer your question how come it works in .NET 2.0 and not in .NET 4.0 , here is a video by Rick from CLR team , where he answers your question.

    HTH
    Thanks Naveen http://naveensrinivasan.com
    Wednesday, April 21, 2010 11:54 PM
  • It is likely caused by some changes in .NET 4.0. But that doesn't mean that it is a bug in .NET 4.0 (even though it could be).
    For example: Imagine that .NET 4.0 decides to allocate memory from higher addresses (e.g. starting at 0x40000000) than 2.0 did (let's say it allocated at 0x00100000) and you have a bug which always reads memory at constant address 0x001000100. Then you are lucky in 2.0 and it works, because the memory is always allocated. But it will likely fail in 4.0, unless something else allocates the memory there at the same address.

    Without knowing exactly why the AV happens on 4.0 it is hard to say more about it.

    Re: In-proc SxS:
    In-proc SxS will not help in case you want 2 assemblies to work with each other. In-proc SxS is good for plugins and extensions, where the 2 CLR versions communicate through COM interfaces (which I guess is not this case).

    -Karel

    • Marked as answer by SamAgain Thursday, May 6, 2010 8:16 AM
    Thursday, April 22, 2010 12:40 AM
    Moderator
  • My mistake I misread the question. It is correct SxS may not help .

    Thanks Naveen http://naveensrinivasan.com
    Thursday, April 22, 2010 12:55 AM
  • OK Karel

    But how can I get it back to work? Did some more tests and it's really not working  in .NET 4.0. When I reference the .net 2.0 class lib in a .NET 2.0 project, it is working. There must be a way do work around this, no?

    Pretty sure the original vendor will not do anything about it because the lib is working in .NET2.0.

    So what can I do to work around this issue? Revert to .NET2.0?


    Blog: mshelp.be
    Thursday, April 22, 2010 9:57 AM
  • I have stumbled upon the same problem.

    In Visual Studio 2008 our solution works fine.In Visual Studio 2010 (Hence targeted the .Net 4.0) throws AV. To further inform the readers:

    My solution has 5 project in it. 4 of them are C# projects targeting .NET 4.0(They were .NET 3.5 previously). C++/CLR project includes managed and unmanaged code in with unmanaged code being OGRE included by using ogre.h. The error raises when any native class function we wrote calls an ogre function/class. But everything works absolutely fine in .net 3.5.


    Until now I have tried many linker and compiler options suspecting that something was changed in compiler options but it was not helpful. I also tried to set the Visual Studio 2010 C++/CLR project configuration to be exactly same as the old one but it too did not helped.

    Well we currently stopped our migration for this it is pretty much my top priority I am simply waiting for answers.

    I also tried running it in debug and release mode it did not create a difference.

    Thursday, April 22, 2010 1:26 PM
  • Spoofer, the answer is still the same: You have to find out what is causing the problem in your application to get an answer. There is no magic "Behave like 2.0" switch. Such thing is truly impossible to implement (from the reasons stated above). The only general advice would be to stay on 2.0 (if you don't want to debug it, or if you cannot make the vendor fix the library which is causing the issue - if it is the library causing the issue).

    Gertwor, there can be more than one million different reasons why your application doesn't work on 4.0. What is the chance that someone else will hit exactly the same issue?
    Try to debug the problem - get full call stack and look at it/post it here. If that's not helpful, try to isolate the problem into a small repro. That's IMO faster than just waiting for a chance to happen.
    BTW: Compiler switches are IMO not likely the reason of your trouble (AFAIK they almost never are).

    -Karel

    • Marked as answer by SamAgain Thursday, May 6, 2010 8:16 AM
    Thursday, April 22, 2010 4:22 PM
    Moderator
  • Yeah I see where the call is going into that library but for me this is blackbox because I can't go into the library itself. I have notified the vendor and will see what happens. Is there a way that you can check what address the lib tries to read/write? Is there anything more I can do?

    I would like to have this class lib that I created run on CLR2 and the program calling the class lib to run on CLR4 because that used CLR4 specific code. Is something like that feasible? Isn't this something this SxS should allow? The different CLR's in the same process?


    Blog: mshelp.be
    Thursday, April 22, 2010 4:38 PM
  • The only alternative is to debug the assembly code - that's rather hard.

    Yes, in-proc SxS could help you with this. Add a COM interface between your library and your application. Your library then can then run on 2.0 while your application can run on 4.0 and they can both communicate via that COM interface.

    -Karel

    • Marked as answer by SamAgain Thursday, May 6, 2010 8:16 AM
    Thursday, April 22, 2010 6:26 PM
    Moderator
  • I think it will get a bit too complex for what it is.
    Think I'l ltry another approach

    Create a new windows service in .NET 3.5, host WCF service in there and do the usage of the library in the WS.

    Do you know of any examples of SxS? Not much on the internet about that topic


    Blog: mshelp.be
    Friday, April 23, 2010 12:17 PM