I couldn't find a solution to this problem. I have a very simple program to generate a PDF using JAGPDF. If i am opening the program from visual studio (same input, same parameters) it runs to the end without errors 90% of the time, but sometimes it throws an exception telling me that symbols not loaded for jagpdf-1.4.dll
If I run the executable directly, 90% it creates the PDF correctly and 10% of the time created a corrupted pdf that I cannot open. How can I solve this problem?
EDIT: I put a screenshot of the error I'm getting, it is very dificult to reproduce because the program runs normally about 90% of the time, so I have to press build several times until it crashes...
EDIT 2: Since it seems the bug is from the library, (I already send them a message reporting it but doubt they'll do something about it because last release was years ago).
I sort of solved the problem by wrapping the function around a loop using try and catch where if the first time it fails then the exception is caught and the function is tried again until it passes. I put a limit of 10 times it can run the loop before terminating it.
The thinking was that, as the events seem to be statistically independent, the loop will reduce the chance of it failing from 0.1 to 0.1^n with n the number of loops.
So now the program is crashing with a probability of 0.0000001% instead of 10%.
With this fix I am happy to report no fails for this weeks data.
Thank you all for pointing me to the direction of the error.
It sounds as if you have found a bug in the PDF library you are using. You have to file a bug report with the PDF software provider. Hopefully they can provide you support.
I've experienced this with every version of Visual Studio starting from 2012 (2012, 2013, 2015 Preview), on multiple computers and multiple projects, but I haven't figured out how to fix it:
Whenever I'm debugging a 64-bit(?) C++ console program, after a few minutes and seemingly completely randomly (when I'm not clicking or typing anything), the console window for the program spontaneously closes and I can no longer debug or step through the program with Visual Studio. When I press Stop and attempt to restart debugging, I usually get ERROR_NETWORK_UNREACHABLE:
// MessageId: ERROR_NETWORK_UNREACHABLE
// MessageText:
// The network location cannot be reached. For information about network troubleshooting, see Windows Help.
#define ERROR_NETWORK_UNREACHABLE 1231L
If I try to attach to the process manually I get the error:
Unable to attach to the process.
The only fix I've found for this is to restart Visual Studio. I can't find any other way to fix it, and I've tried running Process Monitor but haven't found anything.
What causes this problem and how can I fix it?
(?) Upon further checking it seems that this only happens in 64-bit mode, but I'm not 100% sure.
Ok, this is just so wrong
I also have issues with this bug, and in my case it occurred every other debug session. Which meant debug -> stop -> debug -> bug -> restart visual studio -> go to start (repeat every minute during the whole day).
Needless to say I was driven to find a solution. So yesterday I tried procmon, spend hours looking at API monitor differences, looked at plugins, netstat, etc, etc, etc. And found nothing. I gave up.
Today
Until today.
To track down a stupid bug in my program today, I launched appverifier. For my application, I ran the 'basics' tests and clicked save. After a few hours this led me to the bug in my program, which was something like this (extremely simplified version):
void* dst = _aligned_malloc(4096, 32);
memcpy(dst, src, 8192);
Obviously this is a bug and obviously it needed fixing. I noticed the error after putting a breakpoint on the memcpy line, which was not executed.
After a stop and 'debug' again I was surprised to find that I could actually debug the program for the second time. And now, several hours later, this annoying bug here hasn't re-emerged.
So what appears to be going on
So... apparently data from my program is bleeding through into the data or execution space of the debugger, which in turn appears to generate the bug.
I see you thinking: No, this shouldn't happen... you're right; but apparently it does.
So how to fix it? Basically fixing your program (more particular: heap corruption issues) seems to make the VS debugger bug go away. Using appverifier.exe (It's in Debugging tools for Windows) will give you a head start.
Why this works
Since VS2012, VC++ uses a different way to manage the heap. Hans Passant explains it here: Does msvcrt uses a different heap for allocations since (vs2012/2010/2013) .
What basically happens is that heap corruption will break your debugger. The AppVerifier basic settings will ensure that a breakpoint is triggered just before the application does something to corrupt the heap.
So, what happens now is that before the process will break the heap, a breakpoint will trigger instead, which usually means you will terminate the process. The net effect is that the heap will still be in-tact before you terminate your program, which means that your debugger will still function.
"Test"
Before using appverifier -- bug triggered every 2 minutes
While using appverifier -- VS debugger has been stable for 5 days (and counting)
This is an environmental problem of course. Always hard to troubleshoot, SysInternals' utilities like Process Monitor and Process Explorer are your primary weapons of choice. Some non-intuitive ways that a network error can be generated while debugging:
Starting with VS2012, the C runtime library had a pretty drastic modification that can cause very hard to diagnose mis-behavior if your program corrupts the heap. Much like #atlaste describes. Since time memorial, the CRT always created its own heap, underlying call was HeapCreate(). No more, it now uses GetProcessHeap(). This is very convenient, much easier now to deal with DLLs that were built with /MT. But with a pretty sharp edge, you can now easily corrupt the memory owned by Microsoft code. Not strongly indicated if you can't reattach a 64-bit program, you'd have to kill msvsmon.exe to clear up the corruption.
The Microsoft Symbol Server supplies PDBs for Microsoft executables. They normally have their source+line-number info stripped, but not all of them. Notably not for the CRT for example. Those PDBs were built on a build server owned by DevDiv in Redmond that had the source code on the F: drive. A few around that were built from the E: drive, Patterns+Practices uses that (unlikely in a C++ program). Your debugger will go look there to try to find source code. That usually ends well, it gives up quickly, but not if your machine uses those drive letters as well. Diagnose by clearing the symbol cache and disabling the symbol server with Tools + Options, Debugging, Symbols.
The winapi suffers from two nasty viral infections it inherited from another OS that add global state to any process. The PATH environmental variable and the default working directory. Use Control Panel + System + Advanced + Environment to have a look at PATH, copy/paste the content of the intentionally small textboxes into a text editor. Make sure it is squeaky clean, some paralysis at the usual mess is normal btw. Take no prisoners. Having trouble with the default directory is much harder to troubleshoot. Both should pop out when you use Process Monitor.
No slamdunk explanations, it is a tough problem, but dark corners you can look in.
I have the same problem. Thought it was related to 64 bit console apps, where it is very easily triggered with almost any debug session. But, it also happens on 64 bit windows apps too. Now I am seeing it on 32 bit windows apps. I am running Windows 8.1 pro on a single desktop with the latest version of vs 2013 and no remote debugging. My (added) extensions are Visual Assist, Advanced Installer, ClangFormat, Code Alignment, Code Compare, Duplicate Selection, Productivity Power Tools 2013, and Visual SVN.
I discovered that the "Visual Studio 2013\Settings\CurrentSettings.vssettings" file gets corrupted. You can delete this file and recreate it by restarting VS or you can try to edit the XML. I then keep a copy of a good settings file that I use to replace when it gets corrupted again.
In my case, the corrupted line begins with
</ToolsOptionsSubCategory><ToolsOptionsSubCategory name="XAML" RegisteredName="XAML"
... and it is extremely long (I think this is why it is prone to corruption).
I just disabled in the Menu
Tools > Options
Debugging > Edit and Continue
Native-only options > Enable native Edit and Continue
and now it does not give the that stupid error which was preventing the starting of the debuggee application.
I also had the same problem with VS2015. It was so frustrating that a simple Hello World program gave this error when I ran debugger for the second time. Tried uninstall and reinstall and didn't work.
Finally, the solution mentioned in https://social.msdn.microsoft.com/Forums/vstudio/en-US/8dce0952-234f-4c18-a71a-1d614b44f256/visual-studios-2012-cannot-findlaunch-project-exe?forum=vsdebug
worked. Reset all visual studio settings using Tools->Import and Export settings. Now the issue is not occurring.
basically, I have a native C++ application which obviously crashed from time to time during code development. After fixing some bugs it runs rather smoothly. However, I noticed a rather weird behaviour which is very confusing to me.
It is a CMake-based project and I have an option of packaging the application into a zip file. When I run the executable from a freshly extracted zip - the application runs normally (and performance is high). However, say, if it crashes couple of times - the next start the behaviour is the same, but everything runs terribly slow. The test case I have (albeit manual) is very straightforward and I can repeat it easily.
Once the application is slowed down all I have to do is to rename the folder the application is located in and the performance rises again. Until it has crashed couple of times.
Obviously, this is not a problem once I get rid of the crashes. However, it seems to me that once the system (Win8.1 x64) detects persistent crashes it runs it in some different mode(?). And it looks like the app that I run from the IDE (MSVS2013) has received this "penalty". So it runs terribly slow even in release mode, let alone debug.
So I have a couple of questions to the community. First, have you ever observed such behaviour? Second, is the reason for slowdown indeed some system-wide information stored upon application crash? And finally, do you have an idea how to fix it?
Note: I could probably move the source folder to a different location, but it would require quite a lengthy rebuild step. Moreover, I'm just curious about what is going on. Also, system restart and full rebuild in the same folder didn't help.
Some context: the application uses Qt4 (also, Qt plugin system), MITK, ITK, VTK, CTK, OpenCASCADE, glew and related libraries all build from source on this machine.
Cheers,
Rostislav.
Pretty much a year after asking this question, and having the problem "self-resolve", I think I found the answer and decided to post it here in case someone would run into similar problem.
It seems to me that my application was put by the system into the fault-tolerant heap (FTH) after several crashes. Some more information on FTH can be found on MSDN. It might make sense to disable the FTH on the developer machine (at least temporarily) when debugging a particularly nasty crash.
I'm working on an application that uses multiple threads to process its data. The app is developped in C++ (Intel C++ comp. 9.1) and uses OpenMP. It is a 64 bit app running on Win7.
The problem is that when I run it during day, it runs correctly. But when I run it during night after the screen has been locked, it enters in a forever loop after a few processes.
To be more precise, the app is called many times for different files to process. The calls are done within a batch file (no problem there).
I found that it enters in the forever loop about 2 hours after the lock screen occurs.
I disabled all power saving settings. But nothing changed.
It is not very clear as description but the reason is that I don't have a clue about the source of the problem. I just hope someone among you could have had the same problem (and found a fix!). If you want more details, just let me know.
Any idea? Thanks in advance!
As my tests go on, I installed the same setup (but in release rather than debug version) on another computer. I ran into the same problem after 20 minutes (after the screen lock) with another set of data. I ran the same data on my own computer (which is not locked) and everything was fine.
I'm mystified!
Are you giving a thread priority that is taking control of the application?
Also, I would suggest taking running it through some kind of profiling, such as VTune as it can point out potential odd cases that could be causing an issue for you. (There is a free evaluation that you can try).
after I compiled my project in C++ (VisualStudio) around 3-4 times, I can do it anymore due to LNK1168 that stands for "VisualStudio can't write into the exe". I've looked up in my TaskManager, the exe is NOT running. Normally I have to wait for like 5 minutes but that isn't a real solution. Any ideas?
ProcessExplorer just tells me, that the handle is invalid and though can't be closed. It remains open all the time...
First thing that comes to mind is to use ProcessExplorer to figure out what process is keeping the file open. Download and start up the tool en select Find from the menu. Enter the (partial) file name and it should show up in the search results. Double click to jump to the process and file handle in the main application window.
I'm guessing Visual Studio is the culprit.
Fortunately, you can also use Process Explorer to close the handle. Right-click and choose Close Handle.
Note that it's not a good idea to go around closing file handles on a regular basis. However, whenever you're in a pickle it can really help solve annoying problems.
If I recall correctly, a similar problem existed way back in VS 6. It had to do with incremental compilation. For a more structural solution, try doing a full rebuild from time to time or disabling incremental compilation all together.
I have been experiencing exactly the same problem (For C# and C++). I have just discovered that having the Application Experience Service disabled seems to cause EXPLORER.EXE To keep .exe files hanging around (locked by the SYSTEM) for several minutes after running that executable.
The solution to this problem, for me at least, was to re-enable the Application Experience service. (I had originally disabled it since it seemed unnecessary - Apparently I was wrong!)
Your exe might still be running. Stop it before recompiling it.