shellexecute versus opening from explorer

Code:

---

        If Not autorunning Then
            ShellExecute 0, "Open", App.Path & "\autosend.exe", "", "", 0

---

windows 10 x64
when i run the above shellexcute, the file appears in the details section of task manager, but not in the background processes, i also tried using shell in place of shell execute
if i change the UAC virtualization to disabled in task manager , then the program will work

when i double click in explorer or from a startup shortcut (the norm) the process starts as a background process and is also in the details tab, all works correctly

i tried adding a manifest to the exe,

Quote:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="X86"
name="IsUserAdmin"
type="win32"/>
<description>Description of your application</description>
<!-- Identify the application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>

---

this changed things, but not for the better, now when using shell the UAC virtualization, shows as disabled, but the process does not show in background processes
when started with shellexecute UAC virtulization shows as enabled and changing it now does nothing to make the process work
quite possibly the manifest is incorrect, i am not well practiced with manifests, there was no manifest prior to adding the above

in case it has any bearing the application has no user interface, just runs as a background process, i can restart the program, from a shortcut, but not programmically

When using 64bit Windows, I have had to do the following

Code:

---

Private Declare Function IsWow64Process Lib "kernel32.dll" (ByVal hProcess As Long, ByRef Wow64Process As Long) As Long
Private Declare Function Wow64EnableWow64FsRedirection Lib "kernel32.dll" (ByVal Wow64FsEnableRedirection As Byte) As Byte
Private Declare Function GetProcAddress Lib "kernel32" (ByVal hModule As Long, ByVal lpProcName As String) As Long
Private Declare Function GetModuleHandle Lib "kernel32" Alias "GetModuleHandleA" (ByVal lpModuleName As String) As Long

Private Function Is64bit() As Boolean
    Dim Ret As Long
    If GetProcAddress(GetModuleHandle("kernel32"), "IsWow64Process") > 0 Then
        IsWow64Process GetCurrentProcess(), Ret
    End If
    Is64bit = (Ret <> 0)
End Function

Public Function RunProg(Hwnd As Long, Path As String) As Long
    If Is64bit Then
        Wow64EnableWow64FsRedirection False
        RunProg = ShellExecute(Hwnd, "open", Path, vbNullString, GetPath(Path), vbNormalFocus)
        Wow64EnableWow64FsRedirection True
    Else
        RunProg = ShellExecute(Hwnd, "open", Path, vbNullString, GetPath(Path), vbNormalFocus)
    End If
End Function

---

The last parameter in

ShellExecute 0, "Open", App.Path & "\autosend.exe", "", "", 0

. . . must be Const SW_SHOWDEFAULT As Long = 10 while now you are passing Const SW_HIDE As Long = 0 so the process is started hidden.

cheers,
</wqw>

@steve the program being called is a vb6 program, so definitely 32 bit, testing with Wow64EnableWow64FsRedirection False, did not resolve the problem

@wqweto changing the last parameter, as shown appeared to make no difference, as there is no UI, i can only see if the process is running correctly from taskmanager background processes
testing if the process is running will return true, but the application will do nothing
the process also starts correctly when started from taskmanager > file > runnewtask

since trying these various things, changing UAC virtualization no longer makes the process run, even though i have changed back to the original code and removed the manifest

edit: on further testing it seems the shelled program runs correctly when the calling program is closed

Code:

---

Private Sub Command1_Click()
ShellExecute 0, "Open", "C:\Users\user\Documents\w10 lapop docs\Documents\vbstuff\vbstuff\AutoSend.exe", "", "", 0
Unload Me
End Sub

---

this does not work from the ide (probably does when vb6 is closed) but works as desired from a compiled exe, still not the desired solution

Frankly I cannot grasp what the problem is and what the expected behavior is. Is this anelevaation problem? Use “runas” verb then.

i just edited my previous post before your response
the program runs as required as a standard user, no elevation should be needed

when the program is opened and runs correctly, it shows in background tasks and also details
when the program is called from any shell type command (i have tried most of the options i can think of) it does not show in background tasks and is not working, even though it shows in the details tab of task manager

as the program has no UI, i am using a separate program, that does configuration tasks and other related stuff to be able to close the hidden process and also restart when required, this is where the problem is

as a work around based on the above test, i can probably just close the program and restart it after shelling the hidden program, unless a more proper solution can be found

edit: i built a very simple test program, with just a sub main, but it did not have the same problem, so it must be being caused by some code in my hidden program
i now have a working version of the workaround, as above

westconn1,

Make sure you are NOT running your compiled executable under any compatibility shim sets. Most (if not all) of the standard compatibility shim sets are known to break the ShellExecute API function!

Elroy

EDIT: I suppose, if you feel you need certain compatibility shims, you could go through and make your own shims database (SDB file), and then attach it to your executable. However, that's a bit beyond the scope of what I want to do on this post. Also, to do that, you'd need to identify the specific shim which is breaking ShellExecute (which I've never done) and remove it from the SDB list. This is all discussed in a few other threads.

Just in case you're not sure what I mean by "compatibility shim sets", I'm talking about these:

Attachment 179751

@elroy, no compatibility shims at all, just compile and run

i get the same issue running from shell, .bat, .cmd, wscript.run
when the calling program closes then the called program runs, it is already running as a process, but is not active while the caller is still running

i tried a very simple test program and the problem did not occur, so i would believe there must be something in the code to cause this issue
i now have a workaround, unloading the caller and restarting, i would probably prefer a better solution, but as it is only for my own use and can go for many days between needing to shell the program, i guess it will do

i only found there was an issue when i was posting some answer for a thread in the forum, but it did explain some problems i had noticed when using
until i deploy the workaround, i know just to restart the program from the exe or shortcut, which in itself might have been enough to solve the issue