I'm setting break points in Visual Studio before running the Local Windows Debugger, and they all say this when the debugger is running, with a small warning label on each break point. I can't see why this would be happening; people have talked about using different versions of Visual Studio and getting this error, but I made this project earlier today, pasting the base code from my professor into a new project created on my copy of Visual Studio 2012.
I found this when trying to fix a strange error in my program that wouldn't go away even though I manually fixed things (it was a string error that claimed I was using an index outside the bounds of the string; setting this value to 0 explicitly did not fix it) so I presume that this is the actual culprit.
Make sure you're properly building the code (Build Solution or Rebuild Solution).
In the output panel you should now be able to locate where the binaries are located.
Make sure you're debugging the said binaries by looking in the Debugging page of your project properties, the Command property should most likely be set at $(TargetPath).
Other things to look for. The project should be "Set as startup project", the program database option should be activated (by default). Don't modify the source after you started debugging.
Related
Randomly (and infrequently), Visual Studio (2017) will abruptly refuse to run my C++ project. This will suddenly start happening in the middle of a session.
Visual Studio will still build the project and generate the executable, however, the following cryptic error message appears every time I want to run my program. No changes were made to the configuration or project and it strangely happens after an innocent build.
(It goes without saying but I tried extensively checking for solutions to this problem and no solution worked or was applicable)
Whether I add a new configuration setting or play with the existing settings (Release/Debug, x86/x64), nothing fixes it except performing a full repair (and that takes a very long time). Creating a new project didn't help either, but running it in VS 2015 is successful.
This happens approximately once a week, so I would greatly appreciate knowing how this error can be fixed (or at least avoided).
After some more experience with it, it appears just to be an issue with Visual Studio when builds are too large and executed too often (it happened to multiple computers). More specifically, it could come about as a result of using many templates and applying a large number of explicit template specializations. By building with only the template specializations I need for testing, the issue doesn't come up.
This is usually caused by VS mixing release and debug binaries for me. I have a script which cleans all the output directories, including the garbage VS puts into the projects .vs and Windows Temp folder. This always fixes the issue for me.
I found a thread of another user on another website with the same problem except he is using Fortran while I am using C++:
https://software.intel.com/en-us/forums/topic/508718
In fact, I can cite her/him:
The problem:
My problem is that in the debug mode the program algorithm works fine except it does not show the values of the variables.
I tried the watch window and also moving mouse over the variable but neither of them works.
I tried very simple codes like Hello World and just defined an integer but the program is unable to show the value of the variable in debug mode.
From time to time the debug mode works correctly. Sometimes I have to restart the debugger 10 times and then it works for 1 time. It does not matter whether I add or remove breakpoints.
My setup:
Windows 7 64 Bit
Visual Studio Ultimate 2013 (from MSDNAA, all original stuff) Version 12.0.30501.00 Update 2.
I have another notebook with Windows 7 64 Bit and the same Visual Studio Version installed -> same problem!
I have the same problem once in a while and the following steps help me solving it:
Make sure optimizations are deactivated in your Debug build. If they are enabled you compiler removes stack frames, puts variable values into cpu registers or inlines whole functions. The debugger does not like optimizations.
Make sure you use a Debug Runtime Library (check 'Runtime Library' in 'Code generation' and select Multithreaded-Debug or Multithreaded-Debug-DLL)
Rebuild your application (right click Project -> "Rebuild"). Sometimes there are problems which can be solved by a rebuild (i.e. when you update source files from repository which are older then your binaries but newer then the source you built the binaries from; or when you update your compiler or libraries and only parts of your application are rebuild).
Disable Minimal Rebuild in 'code generation' option page. It may mess up you program database.
If everything fails you may try to create a clean new project with default settings and add all your existing .cpp/.h files. This way you make sure your settings are not messed up.
If you are using global variables defined within a namespace you always have to enter the namespace into the watch window (i.e. a variable 'x' defined in namespace 'Y' must be watched as 'Y::x')
Use getchar(); at the end of the program or at the end of a cout statement. In my experience, I had to use getchar(); multiple times to show the variables and the solution. Try it!
I've a solution with ceratin no: of projects (all of them EXE projects in VC++).
I use VS2013.
This is tied to a version control system (Perforce).
I see that as soon as I start building any of the projects in this particular solution, the VS gets hung.
I see a text "Not Responding" at the top of the VS window.
Howvever teh compilation happens successfully but it takes a very long
time for the compilation due to this hang.
Id the expected compilation duration is "10seconds" it takes 3 mins to compile.
THis problem is seen in both Relaese and debug mode.
A point to note it that the very same projects were building super fast few days back & this issue started few days back.
Evevry other solution and it's projects (except this particular solution projects) are compiling very fast.
Any help is really useful.
You can also try to reset Visual studio settings trough:
Tools > Import and Export settings > reset all settings
this will reset all enviroinment settings, then restart visual studio.
edit:
I would also create a new project and copy/paste header and source files from old project to new one, and then compile.
I am not sure if you are using the P4VS Perforce Plugin with Visual Studio or not. However, there is a possibility that the compile is changing files that are checked into perforce or possibly somehow triggering an update. If you are using P4VS, please try building with it disabled and see if that
builds faster.
Try restarting your computer to see if that works. You may have some memory that was leaked from your program which is making it compile slower than usual. A restart of the computer should free all the memory.
Environment: I have a .NET 4.0 solution that references some Visual C++ projects. Visual Studio 2010.
If I build my solution and run the resulting .exe right from the bin directory, I can reproduce my bug. But if I run it hitting the "play" button in Visual Studio (or if I run the process and attach to it) I can step through the code, and everything works as normal.
For reference, the problem I'm getting is an Access Violation which is most definitely happening the C++ code.
But more broadly, I'm wondering what other reasons there might be that attaching a debugger to a process "fixes" the issue.
MS VS is working like a sandbox. When you are starting app in that sandbox, your program inherits all settings from solution properties (or just VS settings). Make sure, all your options provided for the environment are correct. If that wont solve the problem, please double check those settings and think what can prevent access violation and uncheck/check it.
If you are using external DLL, those from you system and those from IDE may have different version. They, of course, may work in both cases, but also may cause problem like access violation or subcribent out of range, depending what is changed inside those dlls.
If its Windows app, try enabling/disabling LargeAddressAware.
If you are compiling stuff for another machine with different OS, it may happen very often due to changes in memory handling by native OS. Memory can sometimes be multi-blocked, extremely fragmented or even multi-deviced, so compile your program only with compilation especially made for targeted OS/machine
debug mode uses assert() and other stuff directly linked to debugging. If something is wrong in debugging and not in release, it means that it is acceptable by machine but not by debugging insertions. In that case you are screwed but if its not appear to be problem in other debugger, well... problem solved, its debugger issue, espeially if release without debugging options is working.
most tiring method - try to pinpoint access violation address and see inside memory windows to what are you referring.
in other cases, supply us with snippet, so we can tell something more!
#Matt this cant be heap problem, it can happen but its extremely rare.
#Huytard its wont happen, without linked dll's program should't even start.
The correct and short answer. Run Windows Updates.
The correct and long answer.
It turns out my build machine hasn't been updated in a while and was using an outdated version of Visual C++ compiler. There was a bug in the compiler for .NET 4 where static constructors were not getting called first before any other types of constructors (only in Release Mode).
But here's the kicker!
If you run the process in the Visual Studio debugger OR you attach to a remote process. The static constructors DO get called first like they are supposed to! (Hence making the issue completely un-reproducible in a debugging environment -- Even in Release mode) I found the issue by placing message boxes all over the place to determine the code path.
http://connect.microsoft.com/VisualStudio/feedback/details/611716/c-cli-class-static-constructor-not-called-in-release-build
Running the green "play" button will use the IDE's environment
Executing from the directory will use the default environment
My guess is that there are probably some DLL's or dependencies that need to be added (directory paths) to your %PATH% environment variable.
Once you identify the dependencies and double check or something with dependency walker - you can set them in a batch script and then call your application.
For example:
#echo off
set PATH=%PATH%;C:\myLibs
call MyApp.exe
I developed a small c++ program in Visual Studio 2012 on Windows7, 64bit (let's call it PC1). On that pc it runs fine!
Since I didn't have a versioning control system like SVN at hand, I copied ALL the project data (the exact folder structure, DLLs, source files, project files...) to a usb stick and moved it to another computer.
On that other engine there's Visual Studio 2010 on Windows7, 64bit (PC2).
So I just changed the platform toolset to v100 as described here.
I successfully compiled the project on PC2 (clean, build) and wanted to run the exe, but the command prompt stayed empty.
I then tried to debug and added a breakpoint at the very first line of main - which wasn't reached, the command prompt was still empty.
Ok, a usb stick is certainly not the most secure solution for data storage, so I gave it another try and moved it again - the problem remains.
Visual Studio's output on PC2 is the same as on PC1, so I couldn't find any anomalies there.
Yeah, there might be many error sources, so where can I start?
And how can I get a more verbose output for troubleshooting?
Or is this even a common phenomenon (perhaps due to different VS versions) and there's an simple way fix it?
This is not a full solution, but at least I'm a tiny step ahead:
In my last comment I wrote:
I took your advices into account and created a brand new project on PC2, VS2010. I exactly followed this guide: http://frozenhamster.wordpress.com/2011/02/11/lapack-on-windows-with-visual-studion-2010/
That didn't work either, so I removed I "out-commented" everything except for a single cout. Voila, that worked!
But as soon as I make use of the desired Armadillo (LAPACK and BLAS), the project compils but does not run.
What's going wrong here?
I don't get any compiler errors!