When I was using Visual Studio 2017 my code was read-only until I hit "break all" or a breakpoint. I'm pretty sure this was out-of-the-box without me changing any option. I'm talking about Windows desktop development with C# and edit-and-continue.
With 2019 I'm always able to change the code, but since the debugger is not paused the change, highlighted with a green squiggle, can't be compiled on the fly.
With 2019 I'm always able to change the code, but since the debugger is not paused the change, highlighted with a green squiggle, can't be compiled on the fly.
This is the "expected behavior" since VS 2019 16.3. It was reported as a bug/regression on developercommunity.visualstudio.com under Able to type while debugging back in Oct 2019, and was resolved as "Closed - Not a Bug". Quoting from the Microsoft-sanctioned comments:
This behavior you described is expected for Visual Studio 16.3. We went through several changes on Edit and Continue and now allow editing the code while the application is running. Any errors or warnings regarding your changes will show up at the Error List Window. In order to apply these changes, you simply have to be on a break state (e.g. break all or stop on a breakpoint) and continue from there.
[...]
The new design allows you to edit the code while running, however these changes won't be actually applied until you stop at a breakpoint or break your app, so you'll have pretty much the same behavior as before.
If you edit your code with Edit and Continue disabled, you'll be notified that the file changed (only if "Require source files to exactly match the original version" is checked), but you shouldn't be forced to restart the app.
Related
I am facing an issue with Visual Studio 2019 (version 16.3.8), when starting an ASP.NET Core 3 WebApi project.
After clicking OK the project starts and runs without any issue. However the pop-up keeps nagging me every time I start my solution.
How can I stop showing it?
What is it trying to tell me anyway?
There seems to be two possible solutions to this, that at least worked for me being on Visual Studio 2019.
Solution
Goto Tools => Options => Debugging => General and then either enable Use Managed Compatibility Mode (thanks to Nan Yu) or disable Enable property evaluation and other implicit function calls.
The second solution faces the drawback that when being in break mode, we have to manually hit refresh on the locals window to see a variables content.
Background
The message is telling us, that our system state may get changed when being in break mode due to implicit property evalution.
By default, we tell Visual Studio debugger to try and evaluate properties implicitly.
This of course requires running code while we are braked, and not only display memory content.
Running code, might potentially change the state of the system, which is not always what we want.
For example, I might be increasing a counter every time the property is accessed,
which means that when the debugger will try to evaluate the property, my code will run,
the counter will be incremented, and my system state is changed, even though I am braked.
https://blogs.msdn.microsoft.com/eliofek/2012/12/12/why-do-we-get-the-function-evaluation-requires-all-threads-to-run/
I had some variables in my watch window that was causing this error popup to happen. Just remove them from your watch window and the error popup should no longer display.
Some time ago, Visual Studio 2019 told me that the "Output" window caused a Visual Studio start-up delay of X seconds and offered me to hide the window on start.
I accepted that offer, and now, after some time, I discovered that having to re-pin the Output window once per Visual Studio session is super-annoying, and that I would like things back the way they were before.
I browsed through the Visual Studio options (specifically Environment/Startup and Environment/"Tabs and Windows"), but I did not find an option to undo that change. What did I miss?
I know that I could reset Visual Studio to default settings, but I want to avoid that, because then I'd lose all my custom settings. (No bounty will be awarded for suggesting this, unless the answer also proves that there is no other option.)
I also know that I could pin the output window and then "save" the layout as a custom layout. I don't want that, I want to modify the "default" layout loaded on start.
(Rubber-duck debugging at its best: 5 minutes after starting a bounty I find the solution myself. Go figure!)
In the Visual Studio menu, go to Help/Visual Studio Performance Manager, which brings up this helpful dialog:
Setting this option back to "Use default behavior" fixes the issue.
I have an odd intermittent crash that only occurs under some circumstances that I am having trouble solving, and I'm seeking SO's advice for how to tackle it.
The bug
At apparently random points, Windows shows the "[App] has stopped working" dialog. It is an APPCRASH in ntdll.dll, exception code 4000001f, exception offset 000a2562. Here's where it gets tricky: this only occurs when running the application under the debugger. However, the debugger does not catch this exception, and at the point where Windows shows this dialog, the IDE is not responding. This bug does not occur when running normally, i.e. not within the IDE debugger.
I can't reproduce it outside the debugger, so I can't run the program and attach when it's already crashed. I can't pause execution when Windows shows this dialog, since the IDE isn't responding. I can manually trace through lines of code to see where it occurs. There are several, and where it occurs is apparently random. For a while it occurred when showing a window (or new form), for a while when creating a thread.
Edit: I have tracked it down to the IDE: if I pause on a breakpoint and click the Thread Status tab, the program will crash immediately with the above dialog even though it is, theoretically, paused. In this situation, the IDE remains responsive. This is really weird.
More information
I have just moved my development environment to VMWare Fusion. The bug also occurs running a build from my old (native Windows) computer on my new computer; it did not occur with the same EXE file on that old computer. This makes me wonder if it is related to Fusion or something in my new setup.
I am running:
Windows 7 Pro x64 on WMWare Fusion 3.1.3 on OSX Lion 10.7.1, all fully updated. Fusion is running in "Full screen" mode on one of my screens.
A colleague running Windows 7 natively (not in a VM) does not encounter this issue. Nor did I on my old Vista computer.
Embarcadero RAD Studio 2010, fully updated (I hope; there are about five updates and getting them all in order is tricky.) I have DDevExtensions 2.4.1 installed, and the latest IDE Fix Pack too: uninstalling both these has no effect.
The application is written mostly in C++, with snippets of Delphi. It is 32-bit.
We use EurekaLog, but the exception is not caught by it either. (Normally, an exception would be caught first by the debugger, then by EurekaLog.)
Running a debug build (no EurekaLog, extra debug info etc, debug DCUs set to true) also reproduces it. However, the "Debug DCUs" option on The Delphi Linking page of the C++Builder project settings dialog seems to have no effect - I can't step into the VCL code and find the line that actually triggers the error.
Codeguard (which detects memory access errors, double frees, access in freed memory, buffer overruns, etc) reports nothing.
This has all the hallmarks of a memory corruption. It only appears when you run under a one particular environment, and occurs at a different location each time. Both classic symptoms.
The best way I know to debug this is to download the full FastMM and run with full debugging options enabled.
If that doesn't help then you are reduced to removing parts of code, one by one, until you can isolate the problem.
Another problem I have seen in D2010 is a problem when mixing local class definitions (i.e. class inside class) with generics. The code generated is fine but the debug DCUs are wrong and when stepping through the code the debugger jumps to the wrong file and dies shortly after. You don't seem to have quite the same problem but there are similarities in the IDE deaths.
Finally I would advise you to suspect your own code rather than VMware. It's always tempting to blame something else but in my experience, whenever I have done so, it was always my code in the end!
I hit a quite similar problem. I've also been developing a .dll and when I've set a breakpoint anywhere in my code, Delphi stopped at the source code line and the host-application crashed immediately.
Closing the "Thread Status Window" in debug layout "fixed" the problem.
I'm working on Windows 7 64-bit and Delphi XE3.
4000001F is STATUS_WX86_BREAKPOINT
In other words, it is INT 3, which was not handled by IDE.
Since it is raised in NTDLL - I would guess that this is indication of memory corruption in system heap. Remember, some Windows code would switch to debugger version when running under debugger. That's why you can not reproduce this when application is running as standalone outside of the debugger - because breakpoint is not generated.
You may try FastMM in full debug mode, but I do not think that it will help you. The corruption does not happen in your memory, it happens in system memory. Yes, perhaps memory allocation scheme will be changed - and your corruption will reveal itself in your code/memory... may be. Try use top-down allocations, try use SafeMM...
Another possible approach would be using Application Verifier.
See also:
Windows has generated a breakpoint
C++ error on Ms Visual Studio: "Windows has triggered a breakpoint in javaw.exe"
http://blogs.msdn.com/b/oldnewthing/archive/2012/01/25/10260334.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2013/12/27/10484882.aspx
Check the The projects dsk file and make sure it does not have a reference pointing to the wrong unit. The fix is to open the dsk in an editor and change the file location to the correct location.
I recently posted this question about my inability to get Delphi 2010 working with remote debugging. I have not had any success and decided to post up a simple step-by-step test technique that might highlight what I'm doing wrong. THIS IS REALLY IMPORTANT to me - I've used Delphi since V1.0 and earn my living from it. Being stuck like this is a pain and its keeping me on Delphi 7.
Anyway, here goes.
Ensure that Delphi 2010 has updates 4&5.
Fire up Delphi 2010, then File | New | VCL Forms App. Put a button on the form, put 'ShowMessage( 'hello' ) in the button OnClick event. Save the project and its unit in a local folder "C:\scratch". Build the project, run it, click the button, 'hello' appears, all fine.
On a networked PC (194.168.1.64), create a new folder "c:\DebugTest" and share it with R/W access.
On 194.168.1.64 install the Remote Debugger from the latest download on the Embarcadero Website (RemoteDebugger_upd2.exe). CLick rmtdbg140.exe to run. Accept the 'un-block' message from the firewall.
Edit the DEBUG build configuration compiler settings with Output directory=\192.168.1.64\DebugTest and unit output directory = c:\scratch - see
Edit the Linking settings to set Debug Information=True, Include remote debug symbols=True. See
Leave compiling settings at defaults. See
Do a full build. The relevant project exe 'project2.exe' and 'project2.rsm' appear in the remote folder \192.168.1.64\DebugTest. Blue dots are visible in Unit2 in the IDE.
Set a breakpoint on the 'ShowMessage' line (the button OnClick event).
Use 'Run' | 'Load Process' with Remote path=c:\DebugTest\Project2.exe, Remote Host=192.168.1.64 and Working directory=c:\DebugTest see
Click 'Load'. The visible breakpoint is immediately disabled, the project starts running and opens the CPU window and stops. Pressing f9 cause the exe to run fully on the remote machine, the button works, you just cannot debug it.
I've tried various 'obvious' things like firewall off but all to no avail. Could some kind person suggest further ideas?
Many thanks.
Well, for me the problem has now been solved, although as a 'work around' and after significant interaction with Embarcadero and an upgrade to XE (which also did not work).
It would appear that the remote debugger is flaky (or possibly just picky) in its ability to load rsm (remote symbols) files - they are still looking into why mine wont load. My rsm file is big at around 50Mb although this is no problem for Delphi 7's remote debugger.
The work around involved upgrading to Delphi XE and then choosing the compiler link option 'Place Debug Information in separate TDS file'. This seems to create a tds file onthe remote target instead of a rsm file and breakpoints then work fine.
I've submitted my rsm and tds files to Embarcadero for investigation as to why this happens.
What Windows OS? Maybe run rmtdbg140.exe as admin.
I run D2010 remote debugging on XP versus XP. My How-To is at http://blog.runbits.com/post/Remote-debugging-Delphi.aspx
I had this problem. Installing Update 4 for Delphi 2010 solved my problem. It is also listed in the list of fixed problems of Update 4.
It is imperative to have correct time zone and clock on remote system. In my case I set up remote debugging and when I load process the breakpoints turned green. I checked remote system timezone and clock, set it right and remote dubugger worked again.
I'm a .NET developer, but I have got a quest - I must find errors in a Delphi project.
After opening a project (Borland Delphi 7) and trying to debug it ('Run' menu), I've noticed all debugging options are inactive (gray).
How can I make it usable?
I'm not sure why the pause button doesn't work, but I have seen Delphi 7 get "confused" and refuse to stop on legitimate breakpoints before.
Make a backup of everything, just in case you don't have the source for all of the DCUs.
Delete the project's DCUs.
Make sure you're including debug information in the project's options.
Do a full build (not just a recompile).
I hope this helps.
The debugger is always active, unless it is explicitly deactivated. Just run the application and the inactive menu items will become active. (For some options you have to have to pause the running application)
Just try pressing F8. This will run the application and pause at the first line of executable code and most of the debugging items will become active.
Hard to tell just from that description, but here are a few pointers.
Make sure you've got a project (.dpr) loaded, and not just a source (.pas) file.
Try to build the project with SHIFT-F9. When it's done, if everything compiles successfully, you'll see blue dots in the "gutter" at the left side of the text editor, showing which lines actually contain debuggable code. If you don't get any of those, go into Project Options and turn on the Debug option, then rebuild.
Once you've done that you should be able to run and debug the app.
Tools-->Debugger Options
Make sure integrated debugging is checked.