Develop Reference

How do I detect if the current Windows is installed in UEFI or legacy mode

My Goal is to simply get, if the current Windows installation is in UEFI or legacy mode. Manually I could just run msinfo32 and look at the "Bios-Mode" row. My current approach is by checking if the "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot" key exists, but I'm not sure if that's a good approach.
I have already tried looking at quite some WMI classes and properties but neither of them had the information I needed. I read that you could use GetFirmwareType() but it seems like that had been introduced in Windows 8 and I want it to run on Windows 7 as well. I also tried the method microsoft gave me, calling GetFirmwareEnvironmentVariableA with a dummy variable and a dummy namespace.
public const int ERROR_INVALID_FUNCTION = 1;
[DllImport("kernel32.dll",
EntryPoint = "GetFirmwareEnvironmentVariableA",
SetLastError = true,
CharSet = CharSet.Unicode,
ExactSpelling = true,
CallingConvention = CallingConvention.StdCall)]
public static extern int GetFirmwareType(string lpName, string lpGUID, IntPtr pBuffer, uint size);
public static bool IsWindowsUEFI()
{
// Call the function with a dummy variable name and a dummy variable namespace (function will fail because these don't exist.)
GetFirmwareType("", "{00000000-0000-0000-0000-000000000000}", IntPtr.Zero, 0);
if (Marshal.GetLastWin32Error() == ERROR_INVALID_FUNCTION)
{
// Calling the function threw an ERROR_INVALID_FUNCTION win32 error, which gets thrown if either
// - The mainboard doesn't support UEFI and/or
// - Windows is installed in legacy BIOS mode
return false;
}
else
{
// If the system supports UEFI and Windows is installed in UEFI mode it doesn't throw the above error, but a more specific UEFI error
return true;
}
}
It told me when I get ERROR_INVALID_FUNCTION, I am running legacy, otherwise it will return a different, more specific error. All I ever got from that code was ERROR_INVALID_PARAMETER on any type of system and I don't know where my mistake is.

That was just a Typo.
3 [DllImport("kernel32.dll",
4 > EntryPoint = "GetFirmwareEnvironmentVariableA",
5 SetLastError = true, ^
Replace the A pointed by the > and the ^ with a W.

How To Add Resources Without Compatibility Error?

The code below creates a copy of the application and adds resources to the copy. When you run the copy that has resources in it, it does it's job first. But when it exits, it exits with Program Compatibility Assistant error:
Image is from Google.
class Program
{
[DllImport("kernel32.dll", CharSet = CharSet.Ansi, SetLastError = true)]
public static extern IntPtr BeginUpdateResource([MarshalAs(UnmanagedType.LPStr)] string filename, bool deleteExistingResources);
[DllImport("kernel32.dll", CharSet = CharSet.Ansi, SetLastError = true)]
public static extern bool UpdateResource(IntPtr resource, [MarshalAs(UnmanagedType.LPStr)] string type, [MarshalAs(UnmanagedType.LPStr)] string name, ushort language, IntPtr data, uint dataSize);
[DllImport("kernel32.dll", SetLastError = true)]
public static extern bool EndUpdateResource(IntPtr resource, bool discardChanges);
private static void modifyResources(string filename)
{
IntPtr handle = BeginUpdateResource(filename, true);
UpdateResource(handle, "10", "1", 0, Marshal.StringToHGlobalAnsi("hello world"), (uint) 11);
EndUpdateResource(handle, false);
}
static void Main(string[] args)
{
string exeFilename = Process.GetCurrentProcess().MainModule.FileName;
string filename = Path.GetFileName(exeFilename);
string anotherFilename = exeFilename.Replace(filename, "_" + filename);
File.Copy(exeFilename, anotherFilename, true);
modifyResources(anotherFilename);
}
}
I don't get it. What mistakes do I make ?
More infos: Win 7 64x, App 86x
Notes (some of these made me think the error was gone):
maybe cleaning up imported libraries might help
maybe Assemblyname or namespace
seems the Compatibility Assistant checks too much and thinks something is wrong when the program does something different than the assistant expects.
project as single exe, no extra dlls (since extinguishing my extra dll, no error occurred)
definitely: error is not running-code related (empty main method)
definitely: error is filename related

Problem is the acquisitiveness of people! There are file names that are unwanted on Windows. Microsoft seems to prevent people from writing new installers. They spawn compatibility errors to prevent certain software from becoming popular and spreading.
Example:
If you use Resource Hacker (tested on Win7):
Go to the installation directory of Resource Hacker.
Run it, close it. No problem,
Rename ResHacker.exe to ResH Installer acker.exe
Run it, close it, see the problem.
Rename it to ResH 4kj545ui45kj4 acker.exe
Run it, close it. No problem.
Rename it back to ResHacker.exe
Punchline:
if (exeFilename.Contains("Installer") && exeFile.isCapableOfResourceManipulation())
makeProblem();
else
ignore();
// assembly info is checked too
// confirmed: after removing all unwanted keywords the error stays away
// even in my old project

Why is this process crashing as soon as it is launched?

We have an IIS WCF service that launches another process (app.exe) as a different user. I have complete control over both applications (and this is a dev environment for now). The IIS app pool runs as me, a domain user (DOMAIN\nirvin), who is also a local administrator on the box. The second process is supposed to run as a local user (svc-low). I am using System.Diagnostics.Process.Start(ProcessStartInfo) to launch the process. The process launches successfully - I know because there are no exceptions thrown, and I get a process ID. But the process dies immediately, and I get an error in the Event Log that looks like:
Faulting application name: app.exe, version: 1.0.3.0, time stamp: 0x514cd763
Faulting module name: KERNELBASE.dll, version: 6.2.9200.16451, time stamp: 0x50988aa6
Exception code: 0xc06d007e
Fault offset: 0x000000000003811c
Faulting process id: 0x10a4
Faulting application start time: 0x01ce274b3c83d62d
Faulting application path: C:\Program Files\company\app\app.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll
Report Id: 7a45cd1c-933e-11e2-93f8-005056b316dd
Faulting package full name:
Faulting package-relative application ID:
I've got pretty thorough logging in app.exe (now), so I don't think it's throwing errors in the .NET code (anymore).
Here's the real obnoxious part: I figured I was just launching the process wrong, so I copied my Process.Start() call in a dumb WinForms app and ran it on the machine as myself, hoping to tinker around till I got the parameters right. So of course that worked the very first time and every time since: I'm able to consistently launch the second process and have it run as intended. It's only launching from IIS that doesn't work.
I've tried giving svc-low permission to "Log on as a batch job" and I've tried giving myself permission to "Replace a process level token" (in Local Security Policy), but neither seem to have made any difference.
Help!
Environment Details
Windows Server 2012
.NET 4.5 (all applications mentioned)
Additional Details
At first app.exe was a Console Application. Trying to launch was making conhost.exe generate errors in the Event Log, so I switched app.exe to be a Windows Application. That took conhost out of the equation but left me the situation described here. (Guided down that path by this question.)
The ProcessStartInfo object I use looks like this:
new ProcessStartInfo
{
FileName = fileName,
Arguments = allArguments,
Domain = domainName,
UserName = userName,
Password = securePassword,
WindowStyle = ProcessWindowStyle.Hidden,
CreateNoWindow = true,
UseShellExecute = false,
RedirectStandardOutput = false
//LoadUserProfile = true //I've done it with and without this set
};
An existing question says I should go down to the native API, but a) that question addresses a different situation and b) the success of the dumb WinForms app suggests that Process.Start is a viable choice for the job.

I ended up opening a case with Microsoft, and this is the information I was given:
Process.Start internally calls CreateProcessWithLogonW(CPLW) when credentials are specified. CreateProcessWithLogonW cannot be called from a Windows Service Environment (such as an IIS WCF service). It can only be called from an Interactive Process (an application launched by a user who logged on via CTRL-ALT-DELETE).
(that's verbatim from the support engineer; emphasis mine)
They recommended I use CreateProcessAsUser instead. They gave me some useful sample code, which I then adapted to my needs, and now everything works great!
The end result was this:
using System;
using System.ComponentModel;
using System.Diagnostics;
using System.Runtime.InteropServices;
using System.Security;
public class ProcessHelper
{
static ProcessHelper()
{
UserToken = IntPtr.Zero;
}
private static IntPtr UserToken { get; set; }
public int StartProcess(ProcessStartInfo processStartInfo)
{
LogInOtherUser(processStartInfo);
Native.STARTUPINFO startUpInfo = new Native.STARTUPINFO();
startUpInfo.cb = Marshal.SizeOf(startUpInfo);
startUpInfo.lpDesktop = string.Empty;
Native.PROCESS_INFORMATION processInfo = new Native.PROCESS_INFORMATION();
bool processStarted = Native.CreateProcessAsUser(UserToken, processStartInfo.FileName, processStartInfo.Arguments,
IntPtr.Zero, IntPtr.Zero, true, 0, IntPtr.Zero, null,
ref startUpInfo, out processInfo);
if (!processStarted)
{
throw new Win32Exception(Marshal.GetLastWin32Error());
}
uint processId = processInfo.dwProcessId;
Native.CloseHandle(processInfo.hProcess);
Native.CloseHandle(processInfo.hThread);
return (int) processId;
}
private static void LogInOtherUser(ProcessStartInfo processStartInfo)
{
if (UserToken == IntPtr.Zero)
{
IntPtr tempUserToken = IntPtr.Zero;
string password = SecureStringToString(processStartInfo.Password);
bool loginResult = Native.LogonUser(processStartInfo.UserName, processStartInfo.Domain, password,
Native.LOGON32_LOGON_BATCH, Native.LOGON32_PROVIDER_DEFAULT,
ref tempUserToken);
if (loginResult)
{
UserToken = tempUserToken;
}
else
{
Native.CloseHandle(tempUserToken);
throw new Win32Exception(Marshal.GetLastWin32Error());
}
}
}
private static String SecureStringToString(SecureString value)
{
IntPtr stringPointer = Marshal.SecureStringToBSTR(value);
try
{
return Marshal.PtrToStringBSTR(stringPointer);
}
finally
{
Marshal.FreeBSTR(stringPointer);
}
}
public static void ReleaseUserToken()
{
Native.CloseHandle(UserToken);
}
}
internal class Native
{
internal const int LOGON32_LOGON_INTERACTIVE = 2;
internal const int LOGON32_LOGON_BATCH = 4;
internal const int LOGON32_PROVIDER_DEFAULT = 0;
[StructLayout(LayoutKind.Sequential)]
internal struct PROCESS_INFORMATION
{
public IntPtr hProcess;
public IntPtr hThread;
public uint dwProcessId;
public uint dwThreadId;
}
[StructLayout(LayoutKind.Sequential)]
internal struct STARTUPINFO
{
public int cb;
[MarshalAs(UnmanagedType.LPStr)]
public string lpReserved;
[MarshalAs(UnmanagedType.LPStr)]
public string lpDesktop;
[MarshalAs(UnmanagedType.LPStr)]
public string lpTitle;
public uint dwX;
public uint dwY;
public uint dwXSize;
public uint dwYSize;
public uint dwXCountChars;
public uint dwYCountChars;
public uint dwFillAttribute;
public uint dwFlags;
public short wShowWindow;
public short cbReserved2;
public IntPtr lpReserved2;
public IntPtr hStdInput;
public IntPtr hStdOutput;
public IntPtr hStdError;
}
[StructLayout(LayoutKind.Sequential)]
public struct SECURITY_ATTRIBUTES
{
public System.UInt32 nLength;
public IntPtr lpSecurityDescriptor;
public bool bInheritHandle;
}
[DllImport("advapi32.dll", EntryPoint = "LogonUserW", SetLastError = true, CharSet = CharSet.Unicode, CallingConvention = CallingConvention.StdCall)]
internal extern static bool LogonUser(String lpszUsername, String lpszDomain, String lpszPassword, int dwLogonType, int dwLogonProvider, ref IntPtr phToken);
[DllImport("advapi32.dll", EntryPoint = "CreateProcessAsUserA", SetLastError = true, CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall)]
internal extern static bool CreateProcessAsUser(IntPtr hToken, [MarshalAs(UnmanagedType.LPStr)] string lpApplicationName,
[MarshalAs(UnmanagedType.LPStr)] string lpCommandLine, IntPtr lpProcessAttributes,
IntPtr lpThreadAttributes, bool bInheritHandle, uint dwCreationFlags, IntPtr lpEnvironment,
[MarshalAs(UnmanagedType.LPStr)] string lpCurrentDirectory, ref STARTUPINFO lpStartupInfo,
out PROCESS_INFORMATION lpProcessInformation);
[DllImport("kernel32.dll", EntryPoint = "CloseHandle", SetLastError = true, CharSet = CharSet.Auto, CallingConvention = CallingConvention.StdCall)]
internal extern static bool CloseHandle(IntPtr handle);
}
There are some pre-requisites to making this code work. The user running it must have the user right to 'Replace a process level token' and 'Adjust memory quotas for a process', while the 'other user' must have the user right to 'Log on as a batch job'. These settings can be found under the Local Security Policy (or possibly through Group Policy). If you change them, a restart will be required.
UserToken is a property that can be closed via ReleaseUserToken because we will call StartProcess repeatedly and we were told not to log the other user on again and again.
That SecureStringToString() method was taken from this question. Using SecureString was not part of Microsoft's recommendation; I did it this way so as not to break compatibility with some other code.

Exception code: 0xc06d007e
This is an exception that's specific to Microsoft Visual C++, facility code 0x6d. The error code is 0x007e (126), ERROR_MOD_NOT_FOUND, "The specified module could not be found". This exception is raised when a delay-loaded DLL cannot be found. Most programmers have the code that generates this exception on their machine, vc/include/delayhlp.cpp in the Visual Studio install directory.
Well, it is the typical "file not found" mishap, specific to a DLL. If you have no idea what DLL is missing then you can use SysInternals' ProcMon utility. You'll see the program search for the DLL and not finding just before it bombs.
A classic way to get poorly designed programs to crash with Process.Start() is by not setting the ProcessStartInfo.WorkingDirectory property to the directory in which the EXE is stored. It usually is by accident but won't be when you use the Process class. Doesn't look like you do so tackle that first.

Why do I get ERROR_ACCESS_DENIED attempting to open a specific job using OpenPrinter?

According to undocprint given a job ID it should be possible to retrieve the spool file for the job using OpenPrinter and ReadPrinter by opening the printer using a string with format "PrinterName,Job xxxx". The MSDN documentation lists this method as well, though with an additional space after the comma "PrinterName, Job xxxx".
Whenever I try to call this method from my test application (using either string format) I get ERROR_ACCESS_DENIED (Windows 8 x64). Why is this and what do I need to do to get this working?
I'm running the test app as admin and have no trouble pausing jobs or printers or accessing other information.
I know the ID I'm using is valid because for an invalid ID it returns ERROR_INVALID_PRINTER_NAME instead.
The code I'm using:
public static void OpenPrinter(String printerName,
ref IntPtr printerHandle,
ref PRINTER_DEFAULTS defaults) {
if (OpenPrinter(printerName, ref printerHandle, ref defaults) == 0) {
throw new Win32Exception(Marshal.GetLastWin32Error(),
string.Format("Error getting access to printer: {0}", printerName));
}
}
[DllImport("winspool.drv", EntryPoint = "OpenPrinterW", SetLastError = true, CharSet = CharSet.Unicode,
ExactSpelling = true, CallingConvention = CallingConvention.StdCall)]
public static extern int OpenPrinter(String pPrinterName, ref IntPtr phPrinter, ref PRINTER_DEFAULTS pDefault);
[StructLayout(LayoutKind.Sequential)]
public struct PRINTER_DEFAULTS {
public IntPtr pDatatype;
public IntPtr pDevMode;
public uint DesiredAccess;
}

Turns out that pDefaults must be passed NULL and then everything works.
This requires changing the extern definition to take an IntPtr or similar.
I haven't seen any documentation about why this might be (in fact the MSDN docs state that this passing NULL should be the same as requesting USE access), but it definitely fixes the issue in our testing.

Permissions. Are you running with administrator rights?

C# works on 32bit but not 64bit

The code below works perfectly on my 32bit machine but I have tested the code now on my 64bit machine, I expected it to work as I was calling the 64bit version of the cscript.exe.
Instead the code gets to the point where it runs the script and then waits for exactly 30seconds then exits the script and continues the rest of the program. The script however appears not to run, (it works fine if I run it manually).
using (var ServerProcess = new System.Diagnostics.Process())
{
var fileInformation = new FileInfo(VBScriptToRun);
string processFileName = IntPtr.Size == 8 ? #"c:\windows\sysWOW64\cscript.exe " : #"c:\windows\system32\cscript.exe ";
string processWorkDir = IntPtr.Size == 8 ? #"c:\windows\sysWOW64\" : #"c:\windows\system32\";
string processArguments = fileInformation.FullName;
ServerProcess.StartInfo.FileName = processFileName;
ServerProcess.StartInfo.WorkingDirectory = processWorkDir;
ServerProcess.StartInfo.Arguments = processArguments;
ServerProcess.StartInfo.CreateNoWindow = false;
ServerProcess.StartInfo.UseShellExecute = false;
ServerProcess.StartInfo.RedirectStandardOutput = true;
ServerProcess.StartInfo.LoadUserProfile = true;
EventLogger.Instance.WriteInformation("Total Integration Service Processing File: Starting to launch the specified program");
try
{
ServerProcess.Start();
ServerProcess.WaitForExit();
}catch(Exception e)
{
EventLogger.Instance.WriteInforamtion("Error running script: " + e)
}

// Sample for the Environment.GetFolderPath method
using System;
class Sample
{
public static void Main()
{
Console.WriteLine();
Console.WriteLine("GetFolderPath: {0}",
Environment.GetFolderPath(Environment.SpecialFolder.System));
}
}
/*
This example produces the following results:
GetFolderPath: C:\WINNT\System32
*/
You should not be trying to access the sysWOW64 folder that is the location of 32-bit windows assemblies. Since you indicated that cscript.exe is a 64-bit process the location of cscript.exe on Windows 7 x64 installation would be the System directory
Source: http://msdn.microsoft.com/en-us/library/system.environment.specialfolder
You should also use the following to determine if the operating system is 64-bit or not.
public static bool Is64BitOperatingSystem { get; }
http://msdn.microsoft.com/en-us/library/system.environment.is64bitoperatingsystem.aspx
I should point out that your current method failing because its trying to [based on the lack information this is only a guess] start the 32-bit process. IntPtr.Size is dependant on the process rather than machine.
If you want to use your method your limited to using the following code to do so.
[DllImport("kernel32.dll", SetLastError=true)]
[return:MarshalAs(UnmanagedType.Bool)]
extern static bool IsWow64Process(IntPtr hProcess, [MarshalAs(UnmanagedType.Bool)] out bool isWow64);
[DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError=true)]
extern static IntPtr GetCurrentProcess();
[DllImport("kernel32.dll", CharSet = CharSet.Auto)]
extern static IntPtr GetModuleHandle(string moduleName);
[DllImport("kernel32.dll", CharSet = CharSet.Ansi, SetLastError=true)]
extern static IntPtr GetProcAddress(IntPtr hModule, string methodName);
You could use
System.Environment.GetEnvironmentVariable( "PROCESSOR_ARCHITECTURE" )
Except that it will return x86 if the process is a 32-bit process.
You are better of using the .NET 4.0 methods.
You could also just use this:
public static bool Is64BitProcess { get; }
This way you know which cscript.exe to actually launch. If your process is 64-bit you should only communicate with a 64-bit process. If its 32-bit then launch only the 32-bit process.
I do believe Windows 7 x64 keeps multiple versions for this exact perhaps in the System and sysWOW64 system directories.
If the process is not actually a 64-bit process then it won't be located at c:\windows\system32 on a 64-bit installation. Looking into it [ why am I forced to research this instead of you? ] Environment.SpecialFolder.SystemX86 will point to the correct location.