I'm using C++ to develop a small Bootstrapper (Setup.exe) application in C++. Using CreateProcess() to launch a .hta (HTML Application) which is used as a UI. It then calls other installers one by one which includes *.exe, *.msi etc.
What I'm trying to do is if I execute my Setup.exe, it asked for UAC for once and launch .hta so that it doesn't required UAC any further. Here is my code:
ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( &pi, sizeof(pi) );
if( CreateProcess(NULL, // No module name (use command line)
"C:\\Windows\\MsHta.exe SetupGUI.hta"// Command line
NULL, // Process handle not inheritable
NULL, // Thread handle not inheritable
FALSE, // Set handle inheritance to FALSE
0, // No creation flags
NULL, // Use parent's environment block
NULL, // Use parent's starting directory
&si, // Pointer to STARTUPINFO structure
&pi // Pointer to PROCESS_INFORMATION structure
// Wait until child process exits.
WaitForSingleObject(pi.hProcess, INFINITE );
// Close process and thread handles.
CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );
I actually saw same in an application installer, but I don't have its Setup.exe's source code.
I think it is nothing to do with how you call CreateProcess. If your main application Setup.exe is launched in elevated mode, all processes lunched by this application will be launched in elevated mode.
In order to have an elevated prompt for your Setup.exe, you need to create manifest.
This simple manifest will trigger the UAC prompt for your application:
but after maybe 10 seconds i receive this error message:
and the debugger show in this code in the file thrdcore.cpp:
// first -- check for simple worker thread
DWORD nResult = 0;
if (pThread->m_pfnThreadProc != NULL)
nResult = (*pThread->m_pfnThreadProc)(pThread->m_pThreadParams);
A thing what make me confuse is that i cant find this position with memory allocation, i do nothing like this in this Function?
No parameter is NULL, what i'm doing wrong?
Any help is welcome
It's impossible to guess what may be wrong with the information you provided. You should use your debugger to set some breakpoints in your code, and check the actual values of the various parameters at the time of the failure. You can also use the stacktrace to see which functions have been called recently.
One of these days I'm going to think of a really clever signature.
Could be wrong here but I think you have to call a Macro just after the thread enters in order to set it up properly, google it, it is well known. (Had this years ago, and havent done any user mode for ages. )
It will be sent to the parent window (in your case the dialog) just before the button is painted. So handle it in your dialog's DlgProc function by creating a brush in the background color that you want, casting it to BOOL and returning it. See MSDN for details.