Sometimes it happens that access to some EXE file is blocked by Windows Defender or others antivirus programs. When you try to start it manually, an error appears as in the screenshot. If you run such files programmatically through the ShellExecute function, then error code 5 (Access denied) is returned.
The question is, is it possible to determine by some function whether it is possible to launch a certain EXE without launching it?
Related
We've all seen "The code execution cannot proceed because xxxxxx.dll was not found." message box in Windows, that pops up when application launch fails due to a missing dependency.
And yet, I cannot figure out how it works: there seems to be no Windows API that allows to discover which DLL is missing after CreateProcess fails with a STATUS_DLL_NOT_FOUND error code...
Does anyone know how this is implemented?
Edit: And yeah, I'd like to obtain name of the missing DLL programmatically, in the process that calls CreateProcess().
there seems to be no Windows API that allows to discover which DLL is missing after CreateProcess fails with a STATUS_DLL_NOT_FOUND error code
Correct, there is no such API available.
Does anyone know how is this implemented?
When an EXE is being loaded prior to starting the execution of its code, the OS's loader scans the EXE's PE header to discover the required DLLs, and then it attempts to load each of those DLLs. If any of those DLLs fail to load, the loader is the one who is displaying the popup message, and it knows which DLL just failed, so it includes that DLL's name in the error message. But that information is not passed down to the caller who originally asked for the EXE to run.
FYI, when using CreateProcess() to run an EXE, you can disable that popup error message by calling SetErrorMode()/SetThreadErrorMode() beforehand, specifying the SEM_FAILCRITICALERRORS flag:
Value
Meaning
SEM_FAILCRITICALERRORS0x0001
The system does not display the critical-error-handler message box. Instead, the system sends the error to the calling process.Best practice is that all applications call the process-wide SetErrorMode function with a parameter of SEM_FAILCRITICALERRORS at startup. This is to prevent error mode dialogs from hanging the application.
We're having a very strange behaviour that I'm unable to identify a root cause for. We use TFS (2017.U2) to compile our legacy system, and are trying to update our build farm from 2008R2 up to 2016. The build system uses PowerShell (v5) to cycle through a list of VBP projects and run a VBS script to compile the projects.
First a bit of basics. UAC is totally disabled (in the registry, not just the slider control), VB6.EXE is also set to XP SP3 compatability, and also to run as the administrator.
Unfortunately, while we can see VB6.EXE start in task manager - it just hangs. Zero activity. Running the same compile interactively works just fine with the same user. This led me to theorize it was an environment problem, however process explorer shows me a valid user environment on the VB6.EXE process.
I don't believe this is due to VB6 throwing an error, as (at least in previous versions of Windows Server) when a background process opens a UI element, the OS indicates to the foreground that the background wants to break in. We dont see that.
We've stubbed this back to a bare minimum code example which I call "test.ps1":
$vb6="C:\Program Files (x86)\Microsoft Visual Studio\VB98\vb6.exe"
Set-Location D:\Builds\27\s\path\prjdir
start-process $vb6 -ArgumentList "/make /out errors.txt project.vbp" -wait
We've been using "start-process" to trigger the VB6 compiles because direct invokation via PowerShell doesn't ingest the parameters properly (they're actually built out of strings passed into the master script in the full blown process... this is the simplified version).
When run interactively (.\test.ps1) this functions properly. The project compiled and I get an errors.txt file written.
When started as a process (start-process .\test.ps1) this again functions properly.
When triggered via a TFS "PowerShell Script" task, this fails to complete the VB6 step - the VB6.EXE can be seen in the Task viewer with the appropriate arguments, and no CPU or IO is associated with the task. No errors.txt file is written. No new DLL is created.
I was able to dummy this down even further and remove TFS from the stack by running the test script from another machine. I ran a remote invokation of the script, and duplicated the result using this command:
PS C:\Users\svc_build> Invoke-Command –ComputerName TestBuild02 –ScriptBlock {powershell C:\Users\svc_build\desktop\test.ps1 }
Again, no errors.txt, and no new DLL. VB6.EXE starts up and just sits there. Process monitor doesnt provide any help in diagnosing what might be the issue.
This now smells of a security door being shut on me - even though the same domain user is running the same job, the difference is that this is a background process... and something is preventing a background process of executing in the same context as a foreground process.
Assuming this assumption is correct, can someone point me at the reason a remotely triggered (background) session isn't able to run VB6.EXE? (and of course, a work around for the situation would be appreciated :) )
If this is not a security issue - can someone identify the real culprit, and the solution to getting VB6 running as a background process, like we're used to seeing it run on W2K8R2?
I'm a bit late to the party, but this sounds like a very similar scenario to what I've just encountered.
Windows 10 v2004
UAC disabled
Compiling by running VB6.exe via a PowerShell script.
Using Bamboo as the build server, running as a Managed Service Account.
When running the build on the server via Bamboo, it hangs. When logging into the build server and running the build manually, it succeeded.
After cutting down the code I was able to reproduce a minimal failing case. The hang was caused by code in a UserControl's UserControl_Initialize method that was manipulating UI controls, but only when that UserControl was placed on a Form in the same project.
During compilation, the compiler will create an instance of the Form (why, I don't know), which in turn creates an instance of the UserControl, which in turn runs the UserControl_Initialize method. I can only assume that running the code at that point resulted in an error of some sort, and that resulted in the compiler hanging.
The same error can be caused by the UserControl_Resize event. That case is reasonably easy to fix by checking if Ambient.UserMode is true before trying to resize the child controls.
Private Sub UserControl_Resize()
If UserControl.Ambient.UserMode Then
' Position the child controls
End If
End Sub
Fixing the UserControl_Initialize methods required the code in those methods to be run at a different point (for example, when the UserControl is given the data to display, we now run the code that was previously in UserControl_Initialize).
Also worth noting is the compatibility settings for VB6.exe that we had to use. Using "Windows XP SP3" compatibility mode resulted in VB6.exe hanging immediately. We had to set it to not use any compatibility mode, but we did have to set Run this program as an adminisrtator, and had that applying for all users.
I want to install ZeroMQ for Ratchet/PHP and I downloaded the installer from http://zeromq.org/distro:microsoft-windows. But I keep getting "NSIS error" whenever I try to install it.
It immediately shows after I run the installer. Different versions, x64 or x86 ones, none of them works. This problem only shows up with ZeroMQ installers.
Does anyone have any idea why does this happen?
P.S. I use Windows 8.1. (Up to date)
This question does not belong here on Stackoverflow but since you posted it here anyway I will give you the technical answer: NSIS needs to open a file handle to itself so it can read the compressed data, it does this by calling GetModuleFileName to get the path and CreateFile to open the file. If this step fails it displays the _LANG_CANTOPENSELF message ("Error launching installer", the text in your screenshot).
A) GetModuleFileName can return a "incorrect" path when filesystem redirection is involved, this is most commonly seen when psexec is used to execute the program from the Windows directory on a remote 64-bit computer and this is probably not the case here?
B) The call to CreateFile can fail, this is most often caused by Anti-Virus software holding a lock/denying access to the file. Try to disable/uninstall any 3rd-party Anti-Virus software...
I am having some problems with a app we are making with wxWidget/wxPython and PyInstaller.
We have compiled the app into a single exe for windows but:
1) On some machines it will not launch at all. It doesn't generate a error or anything in the app logs. It just stops almost immediately.
2) On some machines it will launch fine from cmd but not from explorer. again, same behavior. It just stops almost immediately. I don't even see it pop up in the process explorer.
3) On some machines it works just fine.
Are there any tips on how I can figure out what is going wrong? Is there a way to launch a exe with a debugger?
There are a few things you may want to look into:
Did you compile it as "one file"? I have heard that one exe may be blocked by some antivirus programs. It uses a few of hacks to get everything in one executable which may be considered malicious.
Did you compile it as Windows app (no console)? You may want to enable console and run it on machine where it does not run at all from console. That way you may see why it crashes.
I've written a program with a manifest that includes requireAdministrator. On Windows 7 systems with UAC enabled, Windows pops up a dialog asking for permissions, as it should. Works great.
If a user starts my program by right-clicking it and choosing "Run as administrator", then Windows 7 also pops up a dialog asking for permissions. However, there are some slight differences in how my program operates in some of the more esoteric parts of my program.
So what are the differences between "Run as administrator" and a manifest with requireAdministrator? Any links to documentation that describe differences would be appreciated.
Edit: This is with UAC enabled.
Edit: As promised below is the full explanation of the difference I'm seeing.
I'm using the EasyHook library to inject a DLL into another process. When my application is run with "Run as administrator", the injected process crashes and EasyHook returns the error "Unknown error in injected assembler code". None of the code in my DLL gets a chance to execute; the crash occurs before then. (Moreover, the crash occurs even if I strip the DLL down to nothing)
If I run my program normally (i.e., elevated via requireAdministrator), everything works fine.
My application is composed of a few different executables. The process that the user launches is not the same process that performs the injection.
With the information given there would be no differences in the permissions between the two processes.
If you request an execution level of "requireAdministrator" via the applications manifest your application will either be launched with the full access token of an administrator or not at all if the user denies consent (see Create and Embed an Application Manifest (UAC) for further information).
The same will happen when a user chooses Run as Administrator.
The only difference is the way that the process is started. When you start an executable from the shell, e.g. by double-clicking in Explorer or by selecting Run as Administrator from the context menu, the shell will call ShellExecute to actually start process execution. The whole process of elevation is hidden inside this function. Kenny Kerr describes this process in more details in Windows Vista for Developers – Part 4 – User Account Control:
ShellExecute first calls CreateProcess to attempt to create the new process. CreateProcess does all the work of checking application compatibility settings, application manifests, runtime loaders, etc. If it determines that the application requires elevation but the calling process is not elevated then CreateProcess fails with ERROR_ELEVATION_REQUIRED. ShellExecute then calls the Application Information service to handle the elevation prompt and creation of the elevated process since the calling process obviously doesn’t have the necessary permissions to perform such a task. The Application Information service ultimately calls CreateProcessAsUser with an unrestricted administrator token.
If on the other hand you want to create an elevated process regardless of what application information is available then you can specify the little-known “runas” verb with ShellExecute. This has the effect of requesting elevation regardless of what an application’s manifest and compatibility information might prescribe. The runas verb is not actually new to Windows Vista. It was available on Windows XP and Windows 2003 and was often used to create a restricted token directly from the shell. This behavior has however changed. Here is a simple example:
::ShellExecute(0, // owner window
L"runas",
L"C:\\Windows\\Notepad.exe",
0, // params
0, // directory
SW_SHOWNORMAL);
So essentially starting an executable using the Run as Administrator option means that ShellExecute bypasses the checks for compatibility settings, application manifests etc and directly requests elevation.
Kenny Kerr's article also has sample code to query the current process' token for its permission using the OpenProcessToken function. Possibly you can use the example to identify that there are no differences in the way your process is elevated.
I'm definitely curious to know which differences you are observing as I strongly doubt they are related to elevation.
As a last thing: Can you double check that you really request a level of requireAdministrator and not by mistake only a level of highestAvailable?
One possible difference might be the rarely used/understood/deliberately-chosen uiAccess attribute. Can you create two manifests, one with uiAccess=false and one with uiAccess=true, then tell us whether one of them gives the same behaviour as you see with right-click-run-as-admin?
The EasyHook documentation for the RemoteHooking class' IsAdministrator property mentions:
Due to UAC on Windows Vista, this property in general will be false even if the user is in the builtin-admin group. As you can't hook without administrator privileges you should just set the UAC level of your application to requireAdministrator.
It's hard to imagine why this is happening, but it is conceivable (especially as you are seeing it happen!) that assets, processes, assemblies, &c, with possibly different trust levels and so forth, will not inherit the elevation of your main app. Setting the requireAdministrator flag may handle/enforce this globally across the entire scope of resources and dependencies. Would love to know how this turns out.
I thought I was seeing a difference between these as well. However, it turned out that in my case the issue was this:
When I click "Run as Administrator" from my file browser (Q-Dir), the working directory is different than when I try simply double clicking an application with requireAdministrator set in the manifest. This changed the behavior of some buggy DLLs I had received. In fact, it turned out that 100% of the differences I saw were due to running from different working directories (specifically, it mattered whether I was on C: drive or a different drive letter) and that the method of getting the program to run as administrator had nothing to do with it.
It's an issue that is specific to my computer's exact configuration, but it is a possible clue into the type of thing that might be happening (or might have happened 7 years ago . . . )