system function on windows 7 failed with access denied error - c++

I am writing a simple c++ app in visual studio 2012 on windows 7 wherein I am using the system command, strangely the system command fails with access denied error. For ex, I am trying to create a directory using system("mkdir C:\abc"), the command fails and the errno is set to EACCESS.
Though I fail to create a new directory programmatically, I can very well create a new directory through the command prompt or through explorer.
Also, the CreateDirectory Windows API works fine, it is the system function that is the issue - because no matter what command I pass to the system function, it fails with the same error EACCESS.
I have also noticed that this is machine specific, running the same program on a different machine is no issue.
Any ideas what could be going wrong on this unfortunate machine.
Things that I have already tried
1) Setting administrator privileges on the application
2) ran the system file checker - no problem detected
3) disable avast
Any help would be great. Thanks.

Related

Error compiling C++ project, giving error permission denied collect.exe: error: ld returned 1 exit status

Hello there I am currently getting into developing C++ applications and am using visual studio code with mingw compiler on windows. I built the application last night however now it's deciding to not let me build it again. The built file has disappeared from the directory, it's definitely isn't running in task manager and my antiviruses haven't quarantined it so I have ran out of ideas since this is my first application I have made.
Okay so I've tried the other options and still didn't work. I have however added another argument "-o a.exe" in the json file and this seems to work well.
shutdown your .exe file from the taskbar and delete it. And then rerun the process. It should work now.

Intermittent, random 'file not found' errors under Windows Subsystem for Linux (WSL)

I'm getting intermitting 'fatal error: ... file not found' errors building C++ application using either gcc 4.8 or clang 3.8 under Ubuntu 16.04.2 running in Windows Subsystem for Linux (WSL), when including C++ header files, but only since installing the Windows 10 April update (Version 1803, OS Build 17134.1) a few days ago.
Example error message from clang compiler:
fatal error: 'boost/preprocessor/list/fold_left.hpp' file not found
Example error message from gcc compiler:
fatal error: boost/mpl/aux_/at_impl.hpp: No such file or directory
I say the error is intermittent because if I re-run the build, the particular error that interrupted the build disappears, and the build runs for a while longer until it either builds successfully or randomly fails to include some other file with the same kind of 'file not found' error.
The timing of this fault and the randomness of it make me suspect it is a new bug in WSL. Anyone else seeing this or have suggestions on how to fix it?
The error is not always in a Boost include, but often is simply because Boost comprises a large proportion of the overall include files. The files being built exist on a shared volume under /mnt/d/.
This has been identified as a multithreading bug (https://learn.microsoft.com/en-us/windows/wsl/release-notes#build-17655-skip-ahead) and should get fixed in a future windows update.
Since it's a multithreading bug, it might be possible to work around it by not using multithreaded builds.
If in a hurry, it might be possible to just get to the windows insider program and use one of the preview builds.
In my case, it was not multi-threading but the path to the toolchain.
The failed case was: toolchain was installed in /mnt/c/.../tools/
A good case was: toolchain was installed in /home/yurir/tools/
I guess the mapping of windows folders with ubuntu folders creates some mess.
Why this happens:
This intermittent issue could be a result of something called the Fast Boot for Windows. This setting is on by default on Windows 10: on shutdown or reboot Windows simply reloads the C:\hiberfile.sys image and then locks its drive partitions for security. (Making changes to your NTFS partition while it is hibernated is risky. Because of this the WSL tool that mounts the partition will not mount it in Read/Write mode, if it sees the hibernation flag.)
To Fix:
Goto Control Panel > Hardware and Sounds > Power Options > Find a setting for "Turn on fast Startup" and uncheck the option. Restart your computer and you should have access to the disk.

Visual Studio 2015 error: Unable to start debugging. Unexpected GDB output from command "-target-select remote :5039". Remote connection closed

I see the following error whenever I try to debug "Cross Platform" under "C++" category: "Unable to start debugging. Unexpected GDB output from command "-target-select remote :5039". Remote connection closed"
I've installed all of the contents when I downloaded Visual Studio 2015 community and I ran it on Windows 10 Pro which supports Hyper-V.
I've been searching a solution for this and I've found an assumption:
"What is your debug target, the VS Android Emulator? When we saw this before it turned out to be a bad emulator image. Do you have this problem with all targets (e.g. if you try a physical device) or just one?"
In my case, I just tried this via Emulator(VS Emulator 5" Lolipop (5.0) XXHDP Phone (0x86 -...)
So I've sent an Email to VS 2015.
And the answer was like this:
"Sorry for the delay in responding we were looking at an emulator image of another user that ran into this problem so I was waiting until we had the results of that investigation to report back. We actually were not able to find anything wrong the emulator itself, our current hypothesis is that it is a network or adb problem interfering with GDB’s ability to connect to GDB server on the remote machine. Do you see this error every time you try to debug, or if you reboot the emulator will it work sometimes right after the reboot? Next time you see the error, can you open the emulator’s console mode by going go the Hyper-V manager and double clicking the emulator. Then find the location your app installed to and run “gdbserver --version" from the app path and let me know what it says? This will validate if the correct version of gdbserver is on the device."
So we are trying to solve this problem but I'm also asking here just in case.
Is there anyone who has magical solution for this problem?
I'll put a comment on this if I figure out how to solve this.
Thanks in advance.
** Following answer is from the manager of Visual Studio 2015:
You are only the second person who has run into this issue, and the first person that ran into it provided their everything works correctly when we run their .vhd on our machines so it appears to be some strange problem where gdbserver (which comes from the Android NDK provided by Google) crashes only when running on certain machines. Unfortunately the .vhd you provided does not appear to be the correct one it won’t boot for me. You can see the .vhd file being used by the emulator if you look under the settings of the emulator in your Hyper-V manager. .However given we got the other person’s .vhd you can hold off providing any additional information at this point. I’m waiting to hear back from the emulator team on if they have any ideas since this appears to be an issue only on specific machines since.
If you don’t mind my asking, if you don’t have a background in computers what inspired you to try C++ on Android? That scenario will be significantly more complicated than doing Java on Android.
It's been almost two months since I got this answer but I haven't got any additional response from them yet. So, I ended up quitting developing an application by using VS2015.
If you run into this problem, there are only two ways to go. Change your computer or stop developing application via VS2015.
If the project name contains spaces, the whole remote debugging fails. Visual Studio also creates weird paths. When checking out the "Blink1 for Raspberry Pi" template, I named the Project "Blink1 for Pi", which resulted in a path like this:
~/projects/Blink1?/for/pi/PI/for/pi....
And all the debugging failed. When I recreated this keeping the project name "Blink1", everything worked fine. It's a pity, that spaces aren't handled here...

Error STATUS_BAD_NETWORK_PATH when running qt executables through developer studio

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
...

Application only runs if you run as administrator?

Edit: This problem only occurs on windows 7 and vista from what I've heard.
I have a very simple app developed with an external graphics library. If I install this app into a program files directory and run it, it will crash immediately but it works fine normally, with exactly the same files. I have realised it is because you need to run the application as administrator for it to work.
I appreciate if this is a problem directly related to the graphics engine I am using, but I don't really think so (but I'm clueless). Can anyone help me?
Edit for more detail:
The application executable and files that are needed to run it are installed into the default program directory - for me, C:\Program Files (x86). If you try and run with without clicking run as administrator, it will simple freeze and say "App has stopped working. Windows is checking for a solution to the problem..." My question is basically, how can I make it so run as administrator isn't necessary?
When a program cannot perform an operation, it (the operation) should fail gracefully. My guess is your application is attempting to do something that it cannot do as a normal user and then fails to check for a return code, and then subsequently crashes. You need to identify what it is your program is doing that it should not be able to do as a normal user. For example (off the top of my head):
Write a file to Program Files (x86)
Write to HKLM
(Without more details) The problem is most likely related to the fact that your program tries to write into the directory and then excepts the file creation/modification to actually have an effect. UAC prevents applications from writing the Program Files directories without administrator privilages. The solution is to redesign your application to not rely on such behavior or store the files in question in one of the intended locations (AppData, etc. folders).
If you right-click on the EXE and go to Properties -> Compatibility there are some options that might help. You could try running the app in compatibility mode for a previous Windows version or if that doesn't work at least mark the EXE to run as administrator by default.