I have a sporadic issue whereby occasionally when I boot my computer, open a solution and start the debugger for a project set to run under IISExpress, that IE opens and shows a diagnose connection problem message. The Output window only shows:
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
The program '[4556] iisexpress.exe: Managed (v4.0.30319)' has exited with code 0 (0x0).
The program '[4556] iisexpress.exe: Program Trace' has exited with code 0 (0x0).
I am running IISExpress w/ Studio 2010 SP1 with MVC3 on Windows 7 (32-bit). Most days my system will start up and everything works fine. Occasionally after a reboot or cold start, the above happens. Typically when I am wireless only (but it has been a while since I've been hardwired). I've tried turning off the wireless card and re-enabling it and that does not change things either.
Typically the only thing I can do is switch back to the studio dev server for a while. Later when I go back to IISExpress it is fine again. (however just toggling the setting does not immediately fix the issue).
I am at a loss on how to debug what is happening. I have looked at my appplicationhost.config and it hasn't changed in a while.
Have you added any custom bindings to the applicationhost.config file at all? How does your machine get its ip address? is it DHCP? I found issues with my iis when my machine was assigned a new ip address which had been previously hardcoded in the config file. Do you normally laucnh VS in administration mode? This can also affect the avialability of the ports.
Related
Well I want to debug my .dll which gets loaded into the process, and it's crashing somewhere. I tried to log which line gets executed last to a file but that din't help much.
Now, when I attach the debugger and the application crashes, MSVC debug freezes the proccess, making it impossible to alt tab to any other window and I'm stuck at a black screen with only Task Manager working. I tried shutting down the applications process, but it's impossible, then I had to shut down visual Studio - left without any clue what could cause the crash.
How can I effectively and without problems debug in this situation?
(remote debugging is not an option, I have no second machine at disposal, and I have no second screen too)
Since this morning I keep getting this same message "Visual Studio Remote Debugging Monitor has stopped working" and no matter how many times I restart VS or Windows, that doesn't help. Unfortunately I must use x64 debugging due to third party components. I had no significant changes on the system. From last time everything worked fine.
I've seen this question
VS2008: Unable to start debugging, Remote Debugging Monitor has been closed
and it helped me to understand what is happening but doesn't help me fix the problem...
I am debugging x64 app in local and remote debugger snaps always at the same point of the app start up. The other application still works fine.
Does anyone have some solution for this?
I had a similar debugger issue where details showed that "Fault Module Name" is SYMSRV.dll. So I've fixed that by ticking off "Microsoft Symbol Servers" (Tools->Options->Debugging->Symbols) and cleaning symbols cache.
Sorry, I'm not good at English. I had the same problem. It only happened on my workstation win7 VS2010+SP1. I found that it happened when the program trying to load the assembly "EnterpriseLibrary.ExceptionHandling.Logging.Configuration.Design.dll". Strangely, this assembly references itself! so when the program execution is passing through the statement Assembly.Load("EnterpriseLibrary.ExceptionHandling.Logging.Configuration.Design") in debug mode, the msvsmon.exe crashes with this error message: "visual studio remote debugging monitor has stopped working".
Go to “Start > Run”. Type the following path and hit Enter
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe
I have VS 2010 Ultimate. I have created empty win32 console solution and replaced it's cpp file with http://pastebin.com/EQJKJK6T I tried to perform CPU Sampling profiling. But for some reason I get the following messages
MessageBox:
Could not launch 'path to exe file'. Previous attempt to profile the
application finished unsuccessfully. Please restart the application.
Output window:
Profiling started.
Warning VSP2355: Some Windows counters will not be collected. Without this data, some performance rules may not fire.
Profiling process ID 4368 (test).
Process ID 4368 has exited.
Data written to e:\projects\test\test101224.vsp.
Profiling finished.
PRF0025: No data was collected.
Profiling complete.
I had this issue, yet bizarrely it only affected one Visual Studio solution. Using the profiler with another Visual Studio solution worked fine.
I tried:
disabling Symantec
uninstalling VMware Player (as mentioned above)
but neither worked.
In the end I amended the registry, setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SysPlant\Start to 4 and rebooted, it then started working.
Tearing my hair out in despair now after hours of fighting and googling. I'm trying to debug a simple CLR method. Setup: Visual Studio 2010, SQL Server 2008 R2 Express, Vista Business SP2. I'm a domain user but a local admin on the machine, and a sysadmin on the local instance of SQL Server. I created a new VS database project, pointed it to my db connection string (used this db before), then it asked me if I want to enable debuggig for the connection, to which I answered yes.
I verified that the project deploys fine (can see the assembly and its procedure appear in SQL Server Management Studio), and that I can call it just fine within SSMS. I then added the very same EXEC code to the Test.sql script in my db project, and marked it as the default debug script. I then set a breakpoint both in Test.sql and CLR code.
But when I hit F5 all I get is the following output:
Canceled by user.
Auto-attach to process '[2144] sqlservr.exe' on machine 'DAWID-PC' succeeded.
The thread 'dawid-pc\sqlexpress [54]' (0x13c4) has exited with code 0 (0x0).
The thread 'dawid-pc\sqlexpress [54]' (0x13c4) has exited with code 0 (0x0).
The thread 'dawid-pc\sqlexpress [56]' (0x109c) has exited with code 0 (0x0).
The thread 'dawid-pc\sqlexpress [56]' (0x109c) has exited with code 0 (0x0).
The program '[2144] sqlservr.exe: dawid-pc\sqlexpress' has exited with code 0 (0x0).
And my debugging session ends right there.
I have c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe running; I can see a message saying MyDomain\MyUsername connected. appear every time I hit F5 in Visual Studio. I don't have a firewall running on my PC, and have no anti virus software installed.
Do you have any idea how to make it work? My real target was remote debugging but I thought I should try local first and iron out any setup quirks before venturing any further...
I had this same problem. It appears to be an issue with your project being configured for .NET 3/3.5. As soon as I changed my platform to .NET 2.0 I could hit my break points. I can't wait until the have .NET 4 integration in SQL Server CLR types.
I came across this error recently using VS2010 and SQL 2008 R2 (both installed locally). I switched off my firewall, etc. and still have no luck. Eventually I stumbled across what looked like a SQL Server memory issue. The SQL Log Files were showing a lot of AppDomain X unloaded messages. Anyway, the led me to here: http://www.johnsansom.com/sql-server-memory-configuration-determining-memtoleave-settings/#axzz1SZM5nqyF
and after changing my SQL Server -g startup option to -g384, hey presto the debugging worked !!
I'm not a SQL DBA so maybe someone can jump in and add to this if they have any knowledge of MemToLeave settings.
Ciaran
in server explorer remove Allow SQL Server debugging, but set Application debugging
Start debugging and VS will request to set Allow SQL Server debugging.
Then it will work.
Abbas Shojaee
Set your break-points in the source..,Build and deploy (Sql server projects will build and deploy when you run, but will not hit any break points you have set!.)
On the Server explorer make sure you have enabled Application Debugging and Allow SQL/CLR Debugging.
On the Server Explorer navigate to the clr stored procedure/function that you want to debug,
Right click and Step Into (Alt+F5) .. After 'Attach security warning' , you will see assemblies being loaded in the output window , followed by this, break point will be hit and you can continue usual debugging tasks.
I have a web application that I've always been able to run in Visual Studio and it debugs just fine (breakpoints work, I can pause execution, etc). Recently, the behavior changed suddenly, and a few things happen:
I start debugging, it lauches IE and loads the application, but after a few seconds (sometimes the page hasn't even displayed yet), Visual Studio acts as if debugging has stopped - I'm able to edit code in VS again, and the "Play" button on the toolbar is enabled. The application continues to run in the IE window just spawned, but I'm not attached to it
During this few seconds that VS is "debugging", because it detaches, my breakpoints show as hollow - as if I'm set to "Release" mode and they won't be hit. In fact, I have a breakpoint set in Page_Load, and it skips right by. I've checked, and I'm set to debug mode, though the compile mode dropdown is missing from my toolbar (I checked in the build properties to ensure I was in debug mode).
Can anybody shed some light here?
It turns out that this was actually a result of an upgrade to Windows Vista. VS wasn't being "Run as an Administrator", which caused it to lack the rights to attach to other processes for debugging. As a result, debugging would stop right after it started. Changing the VS shortcut to run as an administrator resolved this problem.
I've experienced samely looking behavior. The cause was in existence of several <system.web> sections (which is allowed by web.config schema). Visual Studio debugger (versions 2008 and 2010 were tested) looks in the first encountered section only. So if your <compilation debug="true"> tag is not in the first one, it thinks that there are no compilation.debug setting present and genrally tryes to add <compilation debug="true"> to the first <system.web>. In some cases VS2008 just silently procceds in this case. For example look here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=510354#details"
Have you installed anything else on the server / workstation recently?
We have a third party app that doesn't allow us to debug, w3wp.exe crashes immediately upon an attempt to debug.
I ran into something similar when I had placed some code in a constructor that was crashing. Exact same issues where the Debug would disconnect just after the application started up.
The short if it, check that you haven't configured a class constructor to run during web startup that is crashing...
Quick windows 7 update: I had to add "localhost" to my list of trusted sites to correct this issue...go figure.
Just a workaround for those (like me) for whom the above solutions do not work: After starting the app you wish to debug, go to Debug -> Attach to Process, and attach it to the process you want to debug. Works on my machine.
In my case, I faced this issue with Visual Studio 2019 and 2022 as well.
I tried upgrading/downgrading Visual Studio versions but nothing helped.
On debugging, I finally found the root cause and sharing it here to help others facing the same problem.
I was using Brave browser with Visual Studio and whenever I uploaded a file in my application, the Visual Studio debugging stopped automatically. The root cause of this issue is the feature in Visual Studio to stop debugging on closing the browser. With Brave browser Visual Studio feels like we have closed the browser on uploading the file. So to fix this issue I have turned of this setting as given here.
You can find this setting here
Tools > Options > Projects and Solutions > Web Projects > Stop debugger when browser window is closed, close browser when debugging stops
Just turn it off and everything should work fine.