I've come across an extremly annoying bug this afternoon. I've been working casually on console application I'm working on for a while now and for no reason at all the VS2012 debugger started hanging when I quickwatch any variables. It hangs for like 15-20 seconds, then I get the message
Function evaluation is disabled because a previous function evaluation timed out
If i then hit F10, the debugger unattach and the process goes on. It crashes on almost every variables that are implicitly declared
Here's the steps I have taken so far to resolve this problem.
Steps I have taken:
Restart VS
Reboot computer
Deleted all breakpoints
Deleted ncb and suo file
Symbol Server is not enabled
No Network location is used, User files are local, project files are
local.
Just My Code enabled/disabled
Ensured Enable .NET Framework source stepping is NOT enabled
Ensured Step over properties is enabled
Ensured Enable source server support is not enabled
Start visual studio with /SafeMode to suppress extensions
Cleared Watch Window (was empty anyway)
Tried changing target platform to x64 and any CPU
Disabling antivius
Resetting visual studio default settings(devenv.exe /ResetSettings)
Reinstall VS
The application I'm debugging :
Type : C# Console application
Target Framework: 3.5
Platform target: x86
For my health sake, please help.
EDIT : I have Visual Studio Update 3, version 11.0.60610.01
EDIT: My computer specs
Windows 7 Ultimate 64 bits
Dell Optiplex 960
Intel Core i5-2400 3.1 Ghz
4 GB RAM
EDIT : I tested on two machines (same code) without visual studio update 3 one that does work, one that does not.
EDIT: A created a simplified console application with the same settings that contains only the following lines of code. I'm getting the hang problem when I watch and then it unattach also. What could be wrong with my machine?
This is a simplified application that hangs the debugger
static void Main(string[] args)
{
var _AppLocation = System.Reflection.Assembly.GetEntryAssembly().Location;
_AppLocation = _AppLocation.Substring(0, (_AppLocation.Length -
(System.Reflection.Assembly.GetEntryAssembly().GetName().Name.Length + 5)));
var directoryInfo = new DirectoryInfo(_AppLocation);
Console.ReadyKey(); //I break here, check the directoryinfo
}
EDIT 10/3/13: This is still unresolved, reinstalling everything(office,framework,vs) completly did not solve the problem. It must be a vs2012 bug that is os/hardware related. I will open a ticket at Microsoft and update if they find out something usefull.
EDIT 10/30/13: This problem have been reproduced on two machines with different hardware configuration. I'm still in contact with microsoft to find the issue. Looks like something related to the framework/windows build/visual studio.
EDIT 11/19/13: I'm still in contact with Microsoft VS escalation team, here's the process monitor log and visual studio crash dump of the problem. http://sdrv.ms/1egpX4O
Solution found in parallelle with the Microsoft VS Escalation team. After analysing the crash dump and process monitor it seems that VS 2012 debugger process checks the store certificate for the Microsoft Root Authority certificate.
Since both computers where in a protected no internet environment, both of them never had been connected online. Thus, they never downloaded the Microsoft CA. Since the CA was absent from the store, it caused the debugger to hang and crash for 3.5 target framework specificly.
Here's the fix from Microsoft VS Team to bypass this check when debugging: (Add in the application app.config)
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
Problem resolved!
I had this same problem with Visual Studio 2015 (including Update 1 and Update 2). So posting my solution (which I submitted to MS) in case somebody else has this problem.
Whenever I tried to use QuickWatch in Visual Studio 2015 Enterprise it would hang the development environment. I can’t click on anything and I’m forced to kill the process via Task Manager. It seems like the modal window opens behind it.
My computer is an HP Spectre and I have another monitor plugged in. I’ve tried it on both monitors.
The fix was to:
Switch to a single monitor
Make the QuickWatch open (which it does)
Move it around (which must
save the window position)
Close it
Plug second monitor in
Now when I use the QuickWatch, it will open correctly
Consider using Process Monitor tool to get a log of file, network, registry and processes operations happen during your investigation. After capturing the log, you may see through it and investigate the possible reason. Or, you can send your log to me and I will investigate it on my side
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
I have done a quick research on msdn and found this :
http://social.msdn.microsoft.com/Forums/vstudio/en-US/2055d3a0-56d9-4134-be23-09a91203e508/quickwatch-says-the-following-for-all-evaluations-function-evaluation-disabled-because-a-previous
Please try the following suggestions to check the result:
Click Tools | Options.. | Debugging | General, and uncheck "Enable
property evaluation and other implicit function calls" option. Step
into (F11) the code to find the root cause of the "time out" Restart
debugging
For more information on the Function Evaluation error, please refer
to: http://msdn.microsoft.com/en-us/library/ms234762(VS.80).aspx
Also, we could get more workarounds of Function Evaluation at blog:
http://blogs.msdn.com/greggm/archive/2005/11/18/494648.aspx
Also it may sound weird but have you the latest update of visual studio 2012?
I had some similar issues when running VS2012 with UAC(User Account Control) turned on, and when having installed some extensions, VisualStudio binds to the running w3p.exe process which works as expected under 1 worker process. Upon allowing multiple worker processes to exist studio cannot track all the independent threads and chokes on the data which reads as corrupted memory.
For myself I have the save setup has yours except for the x64 bit. This always gave me headache in programming... Visual Stutio is 32 bit as long as i know and there is surely a reason why... Anyway you sample work and no hang happend... I cannot tell you exactly why it happened but i'm sure it's a 64 bits related environment of development.
I tried provided code.
VS2012 Ultimate works fine on debug settings and on release setting.
I tested on two differents PCs (desktop and surface Pro)
I also forced x86 setting instead of AnyCPU.
Here is my output for the test application :
http://beehiver.jurion.me/debug%20working.png
I recomend complete uninstall all VS and ALL versions of .net and reinstall. It seems to be a problem on your laptop.
I had the same problem. I suppose its more to do with the hardware configuration. I recently upgraded from 4GB ram to 8GB with Vs 2012 and have never been able to replicate the problem. I used to consistently get this error with the earlier Hardware config.
This Problem happens when your code is waiting for some previous threads to finish there execution,also try to delete .suo file then restart visual studio
This may be related Console.ReadKey() problems/bugs.
http://blogs.microsoft.co.il/blogs/dorony/archive/2012/09/12/console-readkey-net-4-5-changes-may-deadlock-your-system.aspx
Does the problems persist if you use a different method of "pausing?"
There are also some disadvantages of VS. For example, if you open two VS at the same time, while you are writing code, it sometimes get into no response and showing "Saving auto recovery Infomation"
Related
I'm having an odd issue with Visual Studio Community 2015. My program runs correctly inside the Visual Studio Editor, and it also runs correctly when the Application .exe is double clicked in the bin/debug/ directory. However, when the Application is run anywhere else on the computer (including the Release directory) the program does not run correctly. I am definitely copying all of the Debug folder to the location of attempted execution so it's not because of that.
When I run the executable, a loading icon appears on the mouse, in Task Manager it appears as a process using about < 500K RAM and stays there until reboot. No window appears at all, and it is impossible to end the process once it has started, meaning it cannot be deleted.
I'm using .NET 4.5.2 primarily however I've tried 4.5 and 4.6 and neither fixed the issue (I've checked and I have all 3 of them installed). I also tried copying the System DLLs locally and that didn't fix the issue either. I also tried creating a minimalist solution (below) containing a project that only printed "Hello World" and quit.
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World");
Console.ReadLine();
}
}
}
This program experienced the same issues except it couldn't even be run within the Debug folder, only within Visual Studio. I then changed the project so it opened, then closed again straight away without printing anything so that it didn't use the System libraries at all, and it did the same thing. I then tried running the program in both 64 and 32 bit forced, (on a 64 bit laptop) and that didn't make a difference either.
I'm using Windows 7 Home Premium - Visual Studio Community 2015
Thanks for any help :)
Another possibility for such a rare issue could be your Anti-Virus program. Some of them like to inject an DLL into each created process to better protect you. But this can also lead to such awkward problems.
The only other way that comes to my mind would be to check the Event Viewer or run Process Monitor to get an idea where the error comes from.
Try using the release configuration and enable Break on all exceptions (Check Managing Exceptions with the Debugger for help on enabling the VS exception handling).
Hopefully this will break visual studio and show you enough information on the exception.
You can also try using Process Monitor to find the issue.
I would highly recommend using a simple hello world program to find out the root cause. My suspicion is on some corrupt .NET framework installation
That's because it's not the proper exe...
In order to get a proper working .exe for you App Right Click on your project in Solution Explorer > Go to "publish" tab > select Publish Now
(Now go to debug folder and find exe)
It will automatically open the "publish" folder which has files for install, but NOW go to your "debug" folder and you will find the working exe there and some other Visual Studio generated files releated to publish that you don't really need
~ ChenChi
As of today I can no longer debug any c# code using Visual Studio. If I use the debugger, breakpoints can be hit, but as soon as execution has paused the trouble begins. Pressing Step Into, or Continue will normally generate an AccessViolationException saying the memory is corrupt and kill the current request. If I then run a further web request I will instead get an SEHException (occurred in Unknown Module).
It gets even more odd, in that if the AccessViolationException doesn't trigger, the program counter that shows the next statement jumps randomly. Code is then executed in random order! (until it crashes).
If no breakpoints are hit then the app will run in debug mode just fine (even with the debugger attached).
I am confident it's not a code issue. I can actually reproduce the access violations with a new project and the following code:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello world");
Console.WriteLine("Access violation"); // This will throw if breakpoint set
}
}
Have deleted VS cache, deleted .suo, cleaned, and tried safe mode. The one possible suspect is that this is on a Windows 10 preview machine, and there was an update last week. I am not really sure where else to go with this to confirm it, or fix it without reimaging the machine.
Changing from Any CPU to just x64 resolved this for me on my "Hello World" test project.
To get working on my original project, which was actually a web project, I had to take a few extra steps.
Update all libraries in the project to x64, not just the web project.
Enable 64 bit IIS express in VS2013 Tools > Options > Projects & Solutions > Web Projects > Use 64 Bit IIS ...
Install Internet Information Services Hostable Web Core through Control Panel (Turn Windows Features On or Off). Before I did this I would get an error when launching 64 bit web projects in the form HttpException (0x80004005): Specified argument was out of the range of valid values. Installing HWC fixed it.
Still none the wiser why any of this is happening, but at least I can debug projects again.
This exception appeared to start out of nowhere and certainly caused me some headache, but I was able to resolve my issue by doing the following:
Go into the properties of the affected Projects
Go to the Debug Tab
Uncheck "Enable native code debugging"
Pls don't mark it as duplicate .. bcoz I have seen all the solutions but nothing is working for my case..
I have two machines devMachine and serverMachine
in devMachine I am developing application with Visual Studio and Now I have a simple Console Application..my need is I need to run this Console Application in serverMachine and debug from devMachine via Remote Debugging.
As told in Microsoft document, I have installed Remote Debugging tool in serverMachine and set the Authentication mode as Native (No Authentication) and run the Console Application in serverMachine.
Now , I have attached the remote process in devMachine's Visual Studio. All are working fine
But only problem is breakpoint is not hitting in Visual Studio
Note: I have placed required .pdb file in serverMachine and set that .pdb file path in devMachine's Visual Studio (Tools->Option->Debugging->Symbols).
Can anyone help me to resolve this issue?
What does the error message on the breakpoints say (if you hover over the breakpoint) - that it's different from the source? --> You can try disabling (from Tools/Options/Debugging) - Enable source file to exactly match the original version
What does the Modules window say - do the PDB's appear as loaded? if not, have you tried loading them manually (from the Modules window, right click the PDB and load)? - Is there an error message if it fails?
--> you might be in a case where the source files in the local machine are different from the ones on the remote one. Try copying everything over and see if that works (PDBs would be in the same folder as the EXE)
There are two reasons for the remote debugger to not hit the breakpoint
Wrong symbols.
Using the wrong .Net framework while debugging ( you can select on the "attach to process" window in visual studio).
Don't attach and just set remote debugging on. Copy all the project files to the identically placed and named folder in the server during post-build.
I had an issue with Visual Studio not breaking at my breakpoints although it looked like everything was setup correctly for the remote debugger on an IIS machine. I searched everywhere for an answer. The issue finally presented itself when I tried to manually attach the VS debug to a process (VS menu --> Debug --> Attach to process...) For some reason, there were multiple processes for the same application pool (there should only be one process, not sure where the others came from) I logged into my IIS server and killed all the processes for my application pool and then restarted the IIS application. When I saw there was only one process for the app pool (as I expected), I tried debugging in Visual Studio and it attached to the correct process. It turns out that when there were multiple processes for the same application pool, it attached to the "wrong" one.
Looking at your screen shot, could it be simply because the break points are in the "main" function which could already have finished before you can attach the debugger?
Suggestion:
Maybe put some artificial wait/delay code of say 20 secs in "main" above the first break point to give yourself enough time to attach to the process before "main" completes.
While debugging through the code, I am getting following error.
A debugger is attached to w3wp.exe but not configured to debug this unhandled exception. To debug this exception, detach the current
debugger.
I tried the fix from the following link, but it won't work for me.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/373e738f-1bc7-4dcb-88b4-ee8e78d72dc1/an-unhandled-exception-was-raised-from-microsoft-net-framework-v-10-11-or-20-but-the-current?forum=vsdebug
It works fine when I use Visual Studio 2012, but it fails when using Visual Studio 2013. I tried repairing Visual Studio 2013, but It never worked.
Do anybody know the fix for it?
Thanks.
Try This
Go to Project Properties
Debug
Change Debug type to Mixed(managed and native) from managed only for both Application and Background process.
You may be encountering this issue if you have native C code (unmanaged) and C# (managed) code in the same project.
Changing the debug type to mixed makes debugging significantly slow.
I've just had this issue and it was solved by enabling 32 bit applications on the website's App Pool, as detailed here (thanks Colm!):
http://colmprunty1.azurewebsites.net/a-debugger-is-attached-to-w3wp-exe/
Sounds like maybe you have just in time debugging turned on. Your program throws and exception that your current debugger is not configured to handle and perhaps the system is launching the just in time debugger. This is a registry setting but can also be controlled via options in Visual Studio.
http://msdn.microsoft.com/en-us/library/k8kf6y2a(v=vs.85).aspx
To disable Just-In-Time debugging by editing the registry
On the Start menu, search for and run regedit.exe
In the Registry Editor window, locate and delete the follow registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\DbgManagedDebugger
If your computer is running a 64-bit operating system, delete the following registry keys also:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\DbgManagedDebugger
Take care not to accidentally delete or change any other registry keys.
Close the Registy Editor window.
Had the same problem. Got this message all the time I wanted to start my app in debug-mode.
Turned out the problem was, that I still had appverifier (http://msdn.microsoft.com/de-de/library/windows/hardware/ff538115(v=vs.85).aspx) linked to my app. Once unlinked everything went back to normal and I could debug normally.
Not sure if anything to do with your problem. Just saying :)
Are you able to modify the source code so that it thows a meaningful exception?
Also try to recompile the source with VS 2013 and check if the debugger runs fine this time.
for some reason this no longer works. I ugraded the winforms solution from VS2008 to VS2010 and on new machine also Windows 7 64bit but id does not allow edit and continue
I haver set the options to enable it and to compile against 86 cpu
any ideas?
also Windows 7 64bit
Edit+Continue only works for 32-bit code. Easy fix, and the default now for VS2010 projects: Project + Properties, Build tab, Platform target = x86. You can of course leave that setting for your Release configuration at Any CPU.
try this link. quoting from it
Edit and Continue is enabled under Tools>Options>Debugging>Edit and Continue
My solution platform is set to x86
My solution configuration is set to Debug
All my projects are building for Debug and x86
For all projects under Projects>Properties>Build the Optimize code is unchecked
tools->options->unselect intellitrace events and call information
I know it's a old question... but I not found a similar answer on another question.
I was having this issue for months. I found today a solution on my PC (win7 x64):
I run VS2010 with administrator privileges (uac enabled, popup appears and I accept everytime that I run vs 2010) this is because I need a 3rd party addon to work.
It appears that running vs 2010 with admin privileges make it run on another account or something else...
I checked one setting on vs2010 that allowed me to edit and continue now again :)
this option is under:
Tools/Options/Debugging -> Edit and Continue -> check "Enable while remote debugging or debugging and aplication running under another user account"
note: vs2010 will show a warning (security related...).. I not sure how dangerous it is... but works
I hope that this solution can help someone.
In my situation, someone added a Reference to the Project's output into the Reference list: in Solution Explorer look under [ProjectName]\References for [ProjectName*] and remove it. If the project is relying on code from a copy of itself, you can't 'Edit and Continue'.
In the warning list you'll see conflicts with imported type messages if this was the cause of the problem.
I've seen this as well. It seems that some stuff of the expressions and lambdas cause this. ;(
I have the same problem and found this info from the MSDN page "How to: Use Edit and Continue (C#)" :
Note
Edit and Continue is not supported when debugging 64-bit code, the Compact Framework, optimized code, mixed native/managed code, or SQL Server common language runtime (CLR) integration code. If you try to apply code changes in one of these scenarios, the debugger puts up a dialog box explaining that Edit and Continue is not supported.
I think the mix of native/managed code is the problem for me (my project indeed mixes them).