I have noticed a frustrating problem during which a standard Winform control will not enter a drag-drop operation during a debug session as it should after calling the control's DoDragDrop method. The source control (from which the drag-drop operation is initiated) acts as if it doesn't support drag-and-drop.
In my case, it turns out that I was running a debug session in a second instance of Visual Studio 2017. When I stopped running that second debug-session instance of Visual Studio (I was able to keep Visual Studio open, I just had to stop my debug session), the drag operation in the first debug-session instance of Visual Studio began working as expected.
Clearly, drag-and-drop should work in two debug sessions open at the same time in two different Visual Studio instances--and sometimes it does on my system. But occasionally something happens (I'm not yet sure what) to "corrupt" the VS IDE or the .NET subsystem that causes a Winform drag operation from no longer functioning.
This behavior occurs even after rebooting and happens in the latest VS Enterprise 2017 IDE (Ver 15.5.6) with .NET 4.7.02556.
I realize that this problem and its solution is rather nebulous but I felt it was enough to be useful here (and I invested a lot of time figuring out what was going on!).
Since some time I register an annoying behavior in Visual Studio 2010 SP1 under Windows Vista. Sometimes my user settings are lost on start up. This happens most of the time, when I had open the same solution parallel in two instances of VS and after closing both, the settings are lost on the next start of VS.
I do not change settings while running the two VS.
Did anyone experience the same behavior?
Of cource I saved my settings, but especially my keyboard short cuts cannot be fully restored, because I overwrote some global default short cuts. So that's what bugs me about it most. ([EDIT] This is an independent problem, see Microsoft Connect.)
Is there a way to get VS not to kill my settings on start?
VS overwrites user settings on close. If you want to avoid such problems, you should close an instance where you made changes last.
When I'm working in VS.Net 2010, then start debugging, seems like a new window profile or something like that kicks in and rearranges/hides windows that I had open previously. Is there any way to disable this "feature"?
No this cannot be disabled.
What you can do to work around it a bit though is the following
Start a debugging session
Arrange the windows to your liking
Stop the debugging session
Close Visual Studio
After this point whenever you start a debugging session it will return to the window arrangument you had at step #2.
Following my last question (see: Problem in hosting ActiveX on Vista (in a Visual Studio 6 C++ application)) I ran into a strange problem. I hope this’ll be a simpler issue to the experts here:
Each time I run certain application like iexplorer or firefox, the Visual Studio 6 suddenly opens up in debug mode with a message “User breakpoint called from code at 0xSOMETHING”.
I can press F5 to continue but the applications run slowly and needless to say I have no wish to debug these applications…
My guess is that when I worked on my VC++ application I placed breakpoints at windows methods like CAxDialogImpl::Create(), AtlAxCreateDialogA() etc’, and for some reason it was kept somewhere.
Of course I now removed all the breakpoints and re-compiled the project but still this keeps happening!
I checked in the tools->options but the “Just-in–time debugging” is not marked.
Any idea?
(I use Visual Studio 6 which I installed on Vista)
Thanks a lot,
Erik
Not sure this helps but anyways:
Try disbaling the default debugger option. (It says Dr. Watson but it depends what you have set as the default debugger)
http://www.bridgetonova.com/2007/09/how-to-disableenable-windows-default.html
Also as per this post Visual Studio 6 is not supported on Vista. Only Visual Basic is.
http://www.itwriting.com/blog/167-visual-studio-6-on-vista.html
You should probably re-ensure yourself that you have removed all calls to DebugBreak() and manual break-points. Also try to ensure that when you recompile you re-register everything to point to the right places (i.e. the activex pointed to by the guid in the registry is actually the latest recompile).
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.