We have some library projects with a VPI extension. Defined in the DPR with library at start and {$E vpi} at end (Options > output settings > Application > Target file extension: vpi).
library appname;
uses
//...
{$E vpi}
Problem: When I run a debug in a VPI project it works only once. After any change it won't hit the break again. Now showing a "green" breakpoint when you run the app. The only way to get it back to work is by closing and open the IDE.
My Co-worker asked me if I have this problem last year, which I didn't. In his machine "when you change anything in your source, even a space in a comment, the break points won't work till you close and open the IDE again" he said.
We've compared lots of config from the IDE and we didn't find anything.
Now for some "no reason" my computer also stopped working with the debug.
I have looked into this topic "Delphi: why breakpoints from time to time are not usable (green highlighted line on IDE)?" with no luck.
I've tried the Clear unit Cache, un-check and check again the debug info, include TD32, include remote debug, uncheck optimization.
I've asked to other teams and they said that some machines works others don't. But they also don't know why.
Maybe someone here have another trick that may help.
Related
i have a solution
it has 2 projects inside.
there are an exe and a website.
the issue occurred when clicking F5 to start the debug process.
when i have set the exe to the default StartUp project. The exe can run normally, and the break point can be reached correctly.
however, when i have set the website to the defualt StartUp project. The website can be launched, however the breakpoint cannot reach. also the version isn't the latest one, it looks like it is loading the last succeed version (no error and warning too)
I have to right click the website project and click start new instance in the Debug every time I have modified something!(which is very troublesome)
Thus, I want to know why my F5 isn't equal to the Start new instance, as it is working normally in the other solutions.
I fixed that but the below procedures after struggled from extra many clicks compiling experience.
the cause is that there is unknown reason that the build checkbox isn't checked in the configuration manager. simply check it and everything looks fine again...
hopefully it can save someone time who suffered from this issue in the future
i coded a big project that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs. I searched a long time to find the heap error, but didnt find anything. The problem is i need the running .exe of the programm, so i wanted to ask if there is a possibility to link the windows debugger to the .exe so it always starts with it.
If it doesn't crash right away, maybe this helps:
You can run the executable.
Open your solution in visual studio. Make sure it's the same build.
Open the DEBUG menu and click attach to process.
A window will open, listing all processes that are running. Select the executable that's crashing
Click the DEBUG menu again and select Exceptions (ctrl-alt-E)
Make sure the checkbox "Thrown" is checked for Common Language Runtime Exceptions
Now crash your application.. It will halt at the line that causes it.
Also look for environment directives. like #IF DEBUG #END IF. or #IF RELEASE That kind of stuff. Tricked me a couple of times too..
Good luck. Hope this helps!
You can do various things. First make sure you have a "big out try block" in main. i.e. put the main logic in a try can catch exceptions and report these clearly. This probably isn't what's happening in your case.
You can attach a debugger - including Visual Studio, to a running process - see the "Attach to process" option under the debug menu. If it's built with debug symbols, which you can do, even for release code this may help. If it's optimised you may find it difficult though.
Finally, you could generate a crash dump and inspect that after it's failed. See docs on MiniDumpWriteDump. There are several examples on its usage. Or you can install an abort handler: See here. This mentions _set_abort_behavior which if invoked with _CALL_REPORTFAULT will generate a crash dump too.
How to avoid the window "No source available" while stepping into debug mode on VS2010 SL5
In Tools, Options, Debug, General Page. Check if you have 'Enable .NET Framework source stepping' enabled, if it is enabled, disable.
I tried all the suggested fixes; Nothing worked for me.
I finally figured out the solution after several hours of trial & error iterations.
It turns out that the 'No Source Available' error is due to a stack-overflow within the VS debugger env.
The C/C++ code function that was supposed to be stepped-into (by VS debugger), was using a variable that was initialized to a stack array of a few MB in size. When I replaced this with a heap allocation, VS was successfully able to step into the code.
This worked for me.
Please note that in my case, the actual code (with the stack allocation) ran without a stack-overflow error within the debugger (if I skip the No source available error). It was just that VS's debugger's was not able to step-into a particular function sitting inside another C/CPP file, because of the internal stack overflow.
Hope this helps.
You can hit Shift+F11 to step out and it will complete whatever unavailable function it is in and stop at the next line (it may be unavailable as well, but continue to use Step Out until you get to code you want to examine.)
Regarding VS2019, a description for the issue is provided at MSDocs.
For the requisite vcruntime and ucrt source files, the problem can occur after importing from a previous VS version which has since been uninstalled.
To prevent VS from using the old directories, find the solution property pages and navigate to the Debug Source Files Dialog Box.
Click the tick button to check the entries where any invalid ones can be removed.
The vcruntime and ucrt source should always exist in the directories, and the path at the top of the Browse to find source code dialog should always show the correct path.
In my case, because of a venerable drive bug, it is given to prompt for the "D" drive instead of the "C" drive. Further, the provided path cannot be pasted over to refresh the view, so, if none the wiser, one has to use the dialog to navigate all the way up to the required location from the desktop or equivalent.
Here there is an extension for this issue:
http://erwinmayer.com/labs/visual-studio-2010-extension-disable-no-source-available-tab/
But in my own experience before finding this article (I was in page but I was trying to fix it myself without reading article) I have fixed this problem just by accepting a confirmation message saying something like "Selected source file is different from compiled assembly. Are you sure you want to use this file for debug?". But I can't remember exactly what I did to get this message. I think there was a linklabel which I clicked on "No source available" window and then confirmation message appeared and after confirm the problem ran away.
This is a pretty niche question, so I am not expecting a huge response...
Basically, I am learning how to use the UDK by following some tutorials, namely this one:
http://forums.epicgames.com/showthread.php?p=27043379#post27043379
So far everything is going pretty well. The only real hangup I've had is getting everything to work in Visual Studio 2005 using this nFringe plugin. For a long time, couldn't get them to work at all. I've gotten into two or three chapters of the tutorial, and I've managed to use Visual Studio to edit the code, but I can't build the scripts within VS; I have to go to UDK Frontend to do that. And worse still, I can only really use Log commands in the unrealscripts to debug anything.
So my question is this: is it even possible to configure these tools in a way that I can put breakpoints in VS and have them be caught when I test the game? I feel as though I don't have something setup correctly.
Yes it is possible. Here are some info which might be useful to you.
First, both your .sln and your .ucproj files must be located in Development/src. Then, under visual studio, right-click your project (.ucproj file in the solution explorer) and open its properties.
You must set, under the General tab:
Target Game: UnrealEngine 3 Mod
UCC Path: ....\Binaries\Win32\UDK.exe
Reference Source Path: ..\Src
Under the Build tab:
check "Build debug scripts"
Under the Debug tab:
Start Game Executable: ....\Binaries\Win32\UDK.exe
Load map at startup: the name of your startup map, without path nor extension
Start with the specified game type: put your GameInfo class used for your mod, ie. MyMod.MyGameInfo
Disable startup movies can be checked to gain time at launch
Enable unpublished mods must be checked.
In your command line, the parameter -vadebug specifies that the breakpoints will be enabled.
After that, you must be able to build your script from Visual, and launch your game by pressing F5.
Breakpoints should work but you can't put them on a variable declaration, you have to put them on a function call, an assignment or a condition statement.
Hope this will help.
I havnt tried using breakpoints yet but I know its possable to build with nfringe and visual studio . You need to add a line to the
udk game / config / udk engine .ini
search for
editpackages
exactly like that , then youll see a block like this
EditPackagesInPath=....\Development\Src
EditPackages=Core
EditPackages=Engine
EditPackages=GFxUI
EditPackages=GameFramework
EditPackages=UnrealEd
EditPackages=GFxUIEditor
EditPackages=IpDrv
EditPackages=OnlineSubsystemPC
EditPackages=OnlineSubsystemGameSpy
EditPackages=OnlineSubsystemLive
EditPackages=OnlineSubsystemSteamworks
then add your own line pointing to a folder named what ever you want but make sure it has a folder in it named Classes and it has the uc files you wnat to compile in it
ModEditPackages=MyTestProject
if you used that line then you are tellign udk you have a folder named
MyTestProject
located in your development/src folder and you want it to compile everything in there
In Visual Studio 2008, after debugging about 1-2 minutes, when I press F10 (Step Over), the debugger hangs and Visual Studio freezes for 5-10 seconds and then go to the next line. Then whatever I do (F10, F5, F11, etc), the debugger continues the execution as if i pressed F5 and all my forms that I was debugging close. I always have to restart the application.
It is very hard to reproduce and it does not occurs every time I want to debug something. Does anyone has a solution ?
EDIT : I've managed to reproduce my problem with the following code :
static void Main(string[] args)
{
XElement e = new XElement("root");
Test(e, 0);
}
static void Test(XElement parentElement, int i)
{
if (i < 1000)
{
XElement element = new XElement("element");
parentElement.Add(element);
Test(element, ++i);
}
}
You need to put a conditional breakpoint on the line "XElement element = new XElement("element");" with the condition "i == 999". Then start the program, wait 2-3 seconds and put normal breakpoint on the line "parentElement.Add(element);". Now VisualStudio freezes and it is impossible to debug. In a WinForm application, it closes all the forms that are open after pressing F10.
But I found that if I disable the debug option "Call string conversion function on objects in variables windows" in "Tools -> Options -> Debugging", I can debug. It is slow but at least VisualStudio doesn't freeze. Does anyone know why it is doing this? Because I don't want to disable this option, it's really annoying to debug without it.
I also noticed that if I only put a breakpoint at the end of the main method, the code runs really fast compare to having a conditional breakpoint in the recursive method.
Try deleting the solution user options file (.suo) where the debug/breakpoint information is stored. You will lose all solution user settings, such as breakpoint locations. When you have "funny" debugging incidents, this is the first thing to try because this file can get corrupted.
If this does not solve the problem, then you have something else going on, such as threading issues, excessive memory fragmentation, garbage collection issues, dispose/finalize issues, and so on.
I found the answer to this question on another Stackoverflow thread. There's a MS hotfix for this issue.
I've found that I get slowdowns like this whenever I have added remote unc shares that don't exist to the list of symbol directories.
Try going to Tools -> Options -> Debugging -> Symbols and make sure that all of the directories in that list actually exist.
I have no idea how that would cause your program to continue after that point however.
Not sure I've ever run into this, but if I were you, if you haven't, delete your bin folder, and rebuild your project. Then run a clean solution to be safe. Sometimes, funky things can happen with your PDB's getting out of date -- so you need to clear them out.
Also, if your calling outside assemblies, remove them and reattach them to make sure you have the most up-to-date assemblies.
I have had this exact same problem just as you described. The MS Hotfix addressed the issue and now I install this hotfix whenever I do a fresh 2008 VS install.
Please download the fix from this link
http://support2.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957912
I know this is an old thread but this occurred when debugging an Excel add-in in my case.
Problem was that my breakpoint was in a background thread and in my watch window I had an old check on the ActiveWorkbook in Excel. That call just like many others should only occur on Excel's main thread.
Once I removed that watch, it debugged just fine again.