13

Okay so I have been having a lot of issues with debugging. I'm using VS2013 Pro and Windows 8.1. Both are up to date. The issue is, when I start debugging, half the time it throws this error:

An unhandled exception of type 'System.AccessViolationException' occurred in System.Windows.Forms.dll

Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Its not my code's fault either. I made a simple test as an example below. Note that I am not referencing System.Windows.Forms from this app.

    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;

    namespace ConsoleApplication2
    {
        class Program
        {
            static void Main(string[] args)
            {
                List<int> testing = new List<int>();
                for(int i =0; i < 50; i++)
                {
                    testing.Add(i);
                }

                for (int i = 0; i < 50; i++)
                {
                    Console.WriteLine(testing[i].ToString());

                }

                Console.ReadLine();
            }
        }
    }

I have no idea what's causing this. It will work if I click okay and run it again, most the time. Occasionally I have to do it twice.

Any ideas?

Stack trace:

enter image description here

leppie
  • 115,091
  • 17
  • 196
  • 297
FrostyFire
  • 3,212
  • 3
  • 29
  • 53
  • 1
    You get that exception in `System.Windows.Forms.dll` by writing a console application. Are you sure that we can reproduce that exception by just running your code? – L.B Jun 18 '14 at 20:35
  • Exactly my point. Its NOT my code. But something to do with Visual Studio I guess. If I have to, I can make a video lol to prove that code produces the error. – FrostyFire Jun 18 '14 at 20:40
  • probably debugger probing/reflecting variables... – T McKeown Jun 18 '14 at 20:41
  • @JABFreeware, Perhaps its a Visual studio extension? The video would be good as it would help us see where the exception is generated from. – Matt Smith Jun 18 '14 at 20:41
  • What you describe is highly unlikely. Is there any other project in the solution? Does this happen when you're not running under the debugger? Is your console program even linking to Windows.Forms.Dll? Do you have any Visual Studio extensions enabled? (If so, disable them.) I can't reproduce your problem. Nor, apparently, can anybody else here. So there must be something different in your configuration. – Jim Mischel Jun 18 '14 at 21:31
  • @JimMischel I added one – FrostyFire Jun 19 '14 at 14:14
  • How about answering the questions in my earlier comment? Also, post the full exception message, *including the stack trace*, and any other pertinent information. From what little I can glean from the video, it looks like it might be just a timing issue: Visual Studio having trouble restarting your program so quickly after you closed it. Does this happen if you wait five seconds between when you close your program and when you start it again? – Jim Mischel Jun 19 '14 at 14:48
  • @JimMischel hmmmm looked fine before I uploaded it :/ Anyway...yes normally if I wait its fine. Emphasis on normally. Still does it sometimes. It doesnt happen unless debugging, and no of course it never references that dll. – FrostyFire Jun 19 '14 at 15:50
  • @JimMischel added stack trace. – FrostyFire Jun 19 '14 at 19:56
  • No idea. If you're not referencing the Windows Forms stuff, then it must be Visual Studio or some Visual Studio extension that you've installed. I can only say that I've never run into this problem. – Jim Mischel Jun 19 '14 at 20:41
  • You've tried restarting / cleaning the project / resetting vs settings / making a new project? – CC Inc Jun 19 '14 at 22:02
  • @CCInc Everything but resetting vs settings. I like my settings :( – FrostyFire Jun 20 '14 at 03:58
  • @JABFreeware It's a known fact that VS has some issues with settings. You can always back them up and if it doesn't help, restore them. http://stackoverflow.com/a/19460071/1482644 – CC Inc Jun 21 '14 at 01:02
  • I had the same issue. My code autocomplete from database on textchanged event. When I moved the code to form_load, I didn't get the error anymore. – Jaz Apr 30 '20 at 04:37

6 Answers6

9

Changing the Platform Target to x86 works for me, It came to a point that stepping through the code was impossible without the forementioned Exception. I run Win 8.1 64-bit and Visual Studio 2013.

FrostyFire
  • 3,212
  • 3
  • 29
  • 53
Null
  • 146
  • 2
  • 5
6

I also ran into this problem on windows10 using visual studio express2015. building to x86 did not fix my problem but the following workaround did the trick:

This issue is caused by the code which gathers return values. It is possible to work around the issue by disabling Managed return values.

  1. Go to the System properties (Win8: WinKey+X, select ‘System’, Win7: Open ‘Properties’ from my computer)
  2. Advanced System Settings
  3. Environment Variables…
  4. Click ‘New’ and add
    • Name: VSDebug_DisableManagedReturnValue
    • Value: 1

source: https://connect.microsoft.com/VisualStudio/feedback/details/819552/visual-studio-debugger-throws-accessviolationexception

craig
  • 61
  • 1
  • 1
4

http://veriworld.verivox.ads/docs/DOC-6011?et=watches.email.document_comment#comment-4629

Seems that in some cases VS/.net framework has memory trampling issues. I really wish people would stop saying 'it cant be' when someone says something breaks.

fred
  • 51
  • 2
1

There is nothing that looks like it may cause issues.

Did you try enabling breaking on exception? This will cause your code to pause when it encounter an exception.

enter image description here

Gerhard Powell
  • 5,965
  • 5
  • 48
  • 59
  • This seems to be a problem with the IDE. Code runs fine if I don't step through it, but I get access violations when I do. – Quark Soup Sep 05 '14 at 11:53
  • 1
    I don't have the solution to the problem but this almost certainly isn't an IDE problem. This behaviour is usually indicative of a threading issue, whereby you're getting some kind of race condition which goes one way on the step through and the other way when you run it straight up. – Levi Botelho Sep 23 '14 at 08:03
1

I can confirm this problem. It occurs in a small (very trivial) WinForms program distributed with my own commercial app. It's never happened in any earlier version of VS going back to VS2005, including those run on the same machine. It only occurs in VS2013. My version of VS has no 3rd-party add-ins other than what's installed with VS itself. Problem occurs even when all code in "Main()" is commented out. I've tried rebooting, disabling virus checker, firewall, etc. Makes no difference which version of .NET my app targets either (2.0, 3.5, 4.0, whatever). It happens frequently but randomly. Sometimes it works, sometimes it doesn't. Go figure.

Larry
  • 796
  • 6
  • 13
  • 1
    I just discovered https://connect.microsoft.com/VisualStudio/feedback/details/819552/visual-studio-debugger-throws-accessviolationexception which discusses numerous scenarios that may impact the situation. Installing .NET 4.5.2 didn't solve it for me, but changing the "Platform target" from "Any CPU" to "x86" did (on the "Build" property page). Not the ideal situation, but it's a start. – Larry Jan 13 '15 at 19:13
  • I get this when debugging a fairly complex Windows Forms application in VS 2015 Enterprise. The error is being thrown by the IBM iDbAccess library, and happens consistently when debugging. If I do not step through, my error logging still picks it up, so the debugging is causing the program to _break_ on the exception, but the exception is happening behind the scenes anyway. I haven't checked to see if the Release configuration has this problem, and it never seems to impact the compiled executable. – Joseph Morgan Jun 08 '16 at 20:51
  • I am experiencing a problem Similar to what Joseph Morgan is describing. I only get the error if I step through disassembled code from an external .NET library. I think thatiDbAccess may be the origin of my problem although the error is thrown by ...UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop. Is anybody else experiencing iDbAccess problems associated with this message? – kingfrito_5005 Aug 19 '16 at 14:53
1

In my case, such VS behavior was caused by Comodo Firewall.

The solution is adding VS Projects folder to Comodo HIPS exclusions list (even if the HIPS is turned off!).

Here is a related thread Comodo forum: https://forums.comodo.com/empty-t98149.0.html

Ultranium
  • 332
  • 2
  • 19