I have written a C++ code that uses some of the Qt static libraries.
I compile the code using MSVS2010 (on Windows 7) and then run the created .exe-file on a second machine.
I have compiled the exact same code on the same machine 2 different times and the .exe code that is generated crashes on the second machine when that machine's (Windows XP) screen saver starts, I have compiled the same code another time (nothing has changed in the code or the compiler or its settings) and the generated .exe-file does work fine.
Has anybody an idea on what can cause this?
Is there a way I can debug this issue?
Could the fact that at different times maybe different other programs are open affect the compilation?
The problem is not with the compilation process (it will always produce the same binary provided you didn't change the sources) but with the execution environment.
There seems to be something on your second machine that makes your program crash intermittently (or it could well be that it has nothing to do with that second machine, and that your program crashes intermittently everywhere). To debug that, you may end up having to install a debugging environment on the second machine and hope the problem arises again, or you could also try to reproduce the crash on your development machine.
Related
I have programmed an application in C++Builder 6, compiled in Windows 95, the application works perfectly.
The error appears when I compile the application on Windows 10. The following error occurs in the header file _bitset.h:
In
template <size_t _Nw>
On the line
_WordT _M_w[_Nw];
array must have at leas one element
Any ideas?
Thank you all for answering...
I finally solved the problem...
Although the version of the class that I had installed on the new pc seemed the same as on the old pc the "boost_1_31_0" the _biset.h files were different, it was enough to replace the ones on the new pc with the old ones and EUREKA.
Thank you all for your time and excuse my English.
Without MCVE source code or BCB6 installed on Win10 we can only guess sohere are few hints instead of direct answer...
First OS related hints:
There where quite a few changes in OS since BCB6 times. The most likely reason for problems are wrong absolute paths on 64bit windows simply copy compiler and IDE stuff from:
[Program Files (x86)]
into:
[Program Files]
that usually works for most of the older IDEs and SW build before 64bit Windows (like GC/GCC + Eclipse).
On top of this Win10 changed process scheduling to the point many older SW does not work properly or at all and even compatibility modes are useless in Win10. My experience with direct successor of BCB6 (BDS2006 Turbo C++ Explorer) is that to run properly you have to:
run IDE as administrator
You can set this in BCB6 icon properties (compatibility).
set IDE process affinity to single CPU
You can set this in Task manager on BCB6 process. Without this the IDE will freeze for few seconds (up to 45sec) every few minutes (or seconds).
Beware if your app is multithreaded You have to set its affinity back to all CPUs somewhere in your App init code. This is done like this:
Cache size estimation on your system?
Just look for SetProcessAffinityMask usage in the last code there.
install font fix for user folder
I do not know if BCB6 needs this but BDS2006 will not work properly without it as after some Win7 update MS changed the policy of user folder and having fonts there is no longer allowed without fix.
If nothing works try to use Win7 there usually works everything on first try without any problems. Old developing tools tend to not work at all or properly on Win10 and newer versions are usually much worse than old some to the point of to be unusable especially for MCU and USB stuff. So its always a good idea to have a backup Win7 PC for development.
Now code related hints:
Different OS mean different compiler #define directives which means some parts of code might be different then on Win95 see:
C++Builder Compiler Version
so some (most likely inbuild) header files you use might be wanting to see some OS version and have numbers that are not handled in code properly causing some parts of code are not compiled. The remedy is simply to look for those #define in code and either change the version numbers or add new entries ...
Also it looks like BDS2006 compiler bug fix can remedy some weird bugs on BCB6 too so see:
bds 2006 C hidden memory manager conflicts (class new / delete[] vs. AnsiString)
Too many initializers error for a simple array in bcc32
I downloaded an open source c++ project which is written linux. I wanted to run in on windows and installed MinGW in order to compile and run it. I have successfully compiled it with "make" command and program runs pretty fast. Later, I moved program to Visual Studio, modified few lines including deleting "sys/time.h" library etc.. but never made a big change in algorithm itself. When I run the code, it runs but much slower than it runs with its compiled version in MinGW.
I haven't change anything in the algoritm. What should be the reason and how can I make it faster again?
Project I mentioned is here: http://perso.esiee.fr/~coupriec/temporal_segm.zip
It basically segments a given image sequence and produces segments with colored randomly.
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 have searched and found no answer to this
I have a weird problem when running executables through developer studio (2008): a basic 'hello world' exe works OK when created through the usual dev studio project creation mechanism, but when trying to run a library based program the software crashes with STATUS_BAD_NETWORK_PATH. The program uses Qt and zlib behind the scenes and is written in C++, but (as far as I'm aware) is not dependent on any particular network locations on initialisation; we do have Sophos installed on the PC too.
The weird thing is that one cant even step into the main: the program fails well before this with the error. If we plug the network in, it starts up just fine ... The odd thing is this only occurs on a specific 64 bit Windows 7 machine.
Does anyone have any tips as to how to trace where the issue is? We've tried tracking using procmon but it is not very revealing; no obvious failures up to the point where the program crashes.
We have now figured out the answer. It transpired that there were 2 issues:
Firstly a wrapper .bat script that was launching developer studio was setting the PATH environment variable: a location in this path was being specified using a UNX style path (e.g. \\a\location\somewhere) rather than a mapped drive. The executables were not actually using this location but when the network was unplugged this it seems that this was disrupting things from dev studio
This, in tandem with a network configuration error on the PC, meant that deep down in the runes, something was failing.
So - advice if you see such an error
Check your PATH and make sure it is sensible
Look in your PC's configuration logs, and see if you can see any networking issues
...
I recently developed a Visual C++ console application which uses inline SSE2 instructions. It works fine on my computer, but when I tried it on another, it returns the following error:
The system cannot execute the specified program
Note that the program worked on the other computer before introducing the SSE2 code.
Any suggestions?
PS: It works when I compile the code on the other computer and run it. I think it has something to do with the manifest from what I've scrounged off the net.
Most likely the use of the SSE2 instructions is requiring a DLL which isn't present on the second system.
Here's a blog entry on how to figure out exactly which one:
How to Debug 'The System cannot Execute the specified program' message
If you've built a debug version , a Release build might work on the other machine.
If not, you need to figure out which Microsoft Visual C++ Redistributable your program requires and install it on the other machine.