I am having a problem with calling the function MsiOpenDatabase (https://msdn.microsoft.com/en-us/library/aa370338(v=vs.85).aspx) from inside a program when I choose to "run as administrator". When I run it under an admin account but without explicitly starting the executable as elevated it all works just fine. This indicates that the path to MSI file etc should be correct.
So, when running elevated the MsiOpenDatabase() I get an error code of 110 (0x6e).
I have tried to call MsiGetLastErrorRecord as explained here (https://msdn.microsoft.com/en-us/library/aa370124(v=vs.85).aspx) but nothing happens when I try to print the code in a message box. It simply doesn't get there.
I do not have Visual studio for debuggning on the target machine, so debugging is a bit of a pain.
Target machine is Windows 7 x64. Application is 32-bit.
But just the pure fact that it works un-elevated but fails when run as an administrator...it feels like there should be some kind of answer to this which can be derived from this fact perhaps?
Thankful for any help!
EDIT:
I finally solved it!
Apparently I had to go to the network share where the MSI file is located (which I am trying to call MsiOpenDatabase on) and right cklick on a file there and choose "run as administrator" because then and only then did I get a UAC dialog box asking for credentials (I mean I was able to open Windows Explorer as admin and navigate to the network share without problem so I never thought that it would be what would give me these peoblems). After haing done that I was able to run my application and it did no longer fail on any MsiOpenDatabase call.
But, why must I do this procedure to get access to run file on a network share since I already had access (execute rights) with the same user but when not elevated? How come Windows needs to ask the same user for credentials if it is already running elevated on the very same account that already has access to the network share? Seems strange to me, but I suppose I am missing some crucial part?
SAMPLE CODE
LPCTSTR szPersist = MSIDBOPEN_READONLY;
MSIHANDLE handleDB;
UINT result = MsiOpenDatabase(strPath, szPersist, &handleDB); // strPath is something like _T("\\server\MSI\Setup.msi");
result variable has value 110 when this error occurrs as explained above and keep the part in the update section in mind. I find it strange, but perhaps someone knows UAC better than me and why I have to provide credentials again by going to a file on the netowrk share and choose to run as admin to get it working (since I have already provided credentials as non-admin with the same account earlier at that very same network share location)?
This is standard UAC behavior since Windows Vista and is not related to MSI at all. Do a google search for "uac network drives".
You should be closing your MSI handles though as I commented above. Use PMSIHANDLE instead of MSIHANDLE.
I'm developing an application using Wosa/XFS and the current problem is that it produce and error on startup saying "The application was unable to start correctly (0xc0000142). Click Ok to close the application."
This is produced by Wfs_Startup call.
BOOL Wfs_Startup(void)
{
WFSVERSION WfsVersion;
return (WFSStartUp(RECOGNISED_VERSIONS,
&WfsVersion) == WFS_SUCCESS);
}
I don't know what may be the course of this error whether it because I didn't load the NI_XFSMgr.DLL or it the 3 DLL files that I put on System32 directory.
Anyone with a knowledge on WOSA/XFS please help me out with the solution. My application is console based at the moment.
I thank you.
This error may occur when you haven't configure xfs registry correctly.
Check your HKEY_LOCAL_MACHINE\SOFTWARE\XFS\XFS_MANAGER node.
All values must be correct.
Another reason may be your application has no access to xfs shared memory file.
Path to shared memory file is set at HKEY_LOCAL_MACHINE\SOFTWARE\XFS\XFS_MANAGER ShareFileName parameter.
This isn't an XFS problem.
This is due to the DLLs you put in to the system32 folder not being signed or digitally no longer valid.
More info and a trick to go pass this can be found from here
The easier solution would be to put those DLLs in the folder where your application is (And that to be outside of system32).
If I have just run CodeBlocks, I can build and run the Hello world and I the prompt shows and everything is fine. I close it, change what is written, and this message appears:
ld.exe||cannot open output file bin\Debug\HellowWorld.exe Permission denied|
I need to do way more difficults programs than a helloworld, and I've seen in several webs this problem addressed, but nothing works:
http://forums.codeblocks.org/index.php/topic,15047.30.html[1]
ld.exe: cannot open output file ... : Permission denied
After much reading, I understand it has something to do with how the program handles memory. It's something like, if it thinks there's still a process in execution, it does not let me build it again. But I do close it. I've tried everything: input any text so the windows closes (and it does), going to window task manager and finishing the process itself. It does not work. The kicker is that, if I let a few minutes pass, I can indeed build again and run it again. It's kinda stupid and I need help to fix this.
Even more links: The first one I don't get it. I downloaded it and checked as it's said in the wiki:
http://wiki.codeblocks.org/index.php?title=Creating_a_new_project[3]
The link:
http://www.reddit.com/r/learnprogramming/comments/1rvmhx/i_just_started_programming_and_stuck_from/[4]
I mean, I can have done wrong even that. But it does compile and build and run the first time arround...
Most likely the program is still running. Then you can't replace its executable.
If it doesn't have a visible user interface then you can forcefully terminate it via Task Manager Shift+Ctrl+Esc.
Or simpler, always build as console program, because then you can just close the program's console window.
So I keep getting this error when trying to compile C++ code using CodeBlocks.
cannot open output file [filename.exe] permission denied
It only started today, and it's sporadic and inconsistent. It usually goes away if I shut CodeBlocks down and restart the project, but not always. Sometimes it even goes away when I just press F9 (build & run) several times. I always check Task Manager, but there are never any .EXEs running with my file's name, or anything related to it.
I've also noticed that if this problem occurs and I then try to delete the .EXE manually or otherwise interact with it, Windows tells me I need administrator permission to do so (this is a private PC, and as far as I know I am an administrator on it).
The first time it occurred, the only thing I had added to the code beyond what was in the previous version was a debugging report sent to cout - hardly anything arcane. It sometimes occurs even when no code was changed from a previous version.
What could this be? It's not game-breaking, yet, but it's irritating and I'd rather it didn't get worse.
EDIT: This is old by now, but just in case anyone else is having similar problems, the workaround I currently use is just to consistently delete [filename.exe] before trying to run the code again. This avoids the problem, though it is annoying.
check that "filename.exe" is not running, I guess you are using Microsoft Windows, in that case you can use either Task Manager or Process Explorer : http://technet.microsoft.com/en-us/sysinternals/bb896653 to kill "filename.exe" before trying to generate it.
I have encountered the same problem you have. I found that it may have some relationship with the way you terminate your run result. When you run your code, whether it has a printout, the debugger will call the console which print a "Press any key to continue...". If you terminate the console by pressing key, it's ok; if you do it by click the close button, the problem comes as you described. When you terminate it in the latter way, you have to wait several minutes before you can rebuild your code.
I just had the same issue. And i experienced that it always happens when i run the programm and change some code without finishing the programm still running. After that the "cannot open ..." message appears.
However i got rid of it by clicking the "Terminate" button at the very top-right side of the console window (red button) and after that "remove all terminated launches" (two x'es right next to the terminate button).
This seems to close the running programm and everything works fine after :) hope this may help anyone
I was having the same problem too and it was driving me crazy:
Windows7 64 bit, MinGW, Eclipse, CDT
Permission denied errors, executable disappearing, ld.exe errors. It would work once, but never again.
Statements like: "cannot open output file ***.exe: Permission denied"
Check your ANTIVIRUS Software. Once I turned off my Antivirus software in workspace then cleaned the workspace and started the project over again I never had the problem again.
This error usually occurs when the IDE has a problem due to a crash or other failure and it still has a hold on the EXE, preventing the user (yourself) from overwriting / deleting the EXE during a rebuild.
Hello I realize this post is old, but here is my opinion anyway.
This error arises when you close the console output window using the close icon instead of pressing "any key to continue"
The problem is related to Sam´s response:
"have encountered the same problem you have. I found that it may have
some relationship with the way you terminate your run result. When you
run your code, whether it has a printout, the debugger will call the
console which print a "Press any key to continue...". If you terminate
the console by pressing key, it's ok; if you do it by click the close
button, the problem comes as you described. When you terminate it in
the latter way, you have to wait several minutes before you can
rebuild your code."
Avoid kill processes, and we have two choices, wait until the process release the .EXE file or this problem will be solved faster restarting the IDE.
You can use process explorer from sysinternals to find which process has a file open.
Try restarting your IDE. It worked for me.
Although I tried to end the process in the task manager, the process never got killed.
I re-installed C::B in drive D, whereas my program files folder is in drive C
I don't know the reason , but it works :)
well,once i had the same problem and after tracking down the process that was getting the file in use i discovered that it was the anti-virus (PANDA) ...i just unlocked the file and simply worked out ....well for my experience i used Unlock 1.9.2 ...try iy out ..
A major cause of this (which I had recently), is if you have this on for example a flash drive.
You can develop and do everything, but on most systems it stops you from running the .exe file from there, whether it be the debug or release version.
In my case - I found a process called
cb_console_runner
I stopped this process and things were ok again.
I had the same Problem. Just rename your .CPP file to other name and try it again.
It worked for me.
FOR LINUX OS...
go to file where u r created file.then usually
......project_name/bin/Debug/project_name.executable here for this executable file you wont be having execute permission then the execute permission.Either by right click if you are unable to change permission then use use open terminal(command promt) to change permission.
first go to that executable file using 'cd' command then use "chmod u+x" then permission is going to change.then go to c::b open and execute you will get output.
only thing for all file u need to do it.
The problem is that you don't have the administrator rights to access it as running or compilation of something is being done in the basic C drive. To eliminate this problem, run the devcpp.exe as an administrator. You could also change the permission from properties and allowing access read write modify etc for the system and by the system.
Make sure to run 7zip in 'Administrator mode' for extracting to Program Files.
Also, temporarily turning off virus protection worked for some people in the past.
I tried what #willll said, and it worked. I didint find exactly the .exe named after my project, but I did kill some weird looking tasks (after checking on the internet they were not critical), and it worked.
I have tried and get output after end task IDE from task manager. Later clean all temporary files from your drive. Start your IDE. Now your .exe working good.
I've been trying to get a program that worked on Windows 2000 to work on Windows 2003. Everything I've had to do so far to get the program to work on Windows 2003 has had to do with incorrect configuration. Right now, this piece of code:
chr = pAdapterEnvPtr.CreateInstance(__uuidof(PFADAPTERMNGLib::PFAdapterEnv));
is returning:
0x8007007E
or in other words:
The specified module could not be found.
I have two other programs and another .dll and I can successfully create instances of those classes. But this seems to fail.
I have used Procmon to try to figure out what the program can't find, but Procmon did not display anything that could indicate that the program could not find something.
In OleView, if I try to create an instance of the class, I see the following image:
If you look on the left side of the image, trying to create an instance of PFComgMng gives me the same error. (PFAdapterEnv and PFCompMng use the same process, PFAdapterMng.exe.) However, PFMQMonitor, PFSend, and PFTrace all work correctly. (Which use PFMQListen.exe, PFSend.dll, and PFTraceService.exe.)
Another thing that I wanted to note is that the following piece of code:
hr = pPFCompMng.CreateInstance(__uuidof(PFADAPTERMNGLib::PFCompMng));
works perfectly fine when it gets called earlier from PFAdapterMng.exe. So it seems like PFAdapterMng.exe can successfully find the module and create the instance, but any other processes that try to create either of the instances of the classes within PFAdapterMng.exe can't find the module, resulting in this error.
Since Procmon isn't helping with this specific case, does anyone know what I could do to figure out what's keeping other processes from finding the module?
UPDATE:
I can't run Dependency Walker with profiling because PFAdapterMng.exe and PFTraceService.exe must be run as services. I tried to run Dependency Walker while profiling OleView and tried to create instances of PFAdapterEnv and PFCompMng to try to find out why I was getting the Module not found message box. Unfortunately, Dependency Walker didn't show that anything was missing.
UPDATE2:
Maybe I missed something in the Procmon log, so I created a new log by capturing events right before I stepped over the call to CreateInstance and right after the call. Maybe someone else could take a look and tell me if i missed it? I simply can't find any indications that PFMQListen.exe could not find something..
Here's a link to a zipped folder with a Procmon file, a .csv file, and a .xml file.
http://www.mediafire.com/?07jq8zj7emmpsvd
UPDATE3:
So, I managed to get Dependency Walker running under Profile mode to create an instance of PFAdapterEnv. Dependency Walker did not find any missing .dll's.
So, Procmon doesn't show anything, and neither does Dependency Walker. I was stepping through the code at the assembly level with ollydbg, and I noticed that the error was created in the function NdrClientCall2. I don't know if this means anything.
Any ideas as to what else I can try? Do people need more information to help me solve this problem? If so, please ask.
UPDATE4:
I tried using /RegServer to register the applications, and it worked. I tried using /RegServer previously, where I just unregistered everything using /UnregServer. This time, I also deleted the component from Component Services which I needed to have because I wanted to run PFAdapterMng under another identity.
So, it seems like everything works when running on /RegServer and double-clicking the applications. However, I would like everything to run under a different configuration.
How do I configure everything to get the applications to work as follows:
PFAdapterMng.exe - Register as /Service and run under another identity through services.msc
PFTraceServer.exe - Register as /Service and run under another identity through services.msc
PFMQListen.exe - Register as /RegServer which will be started by PFAdapterMng
PFMQSend.dll - Registered with Regsvr32 and loaded by PFAdapterMng
Thanks,
Krzys
My guess is that it is related to the search path of some DLL dependencies of the executable.
You can try the "Dependency Walker" on every module to see if all DLL are available: http://www.dependencywalker.com/
And update the search PATH if needed.