We Keep Coding

Programmatically check Windows 10's case sensitive directory attribute

Since April 2018, Windows 10 has had the ability to get or set if a directory was marked as case sensitive using fsutil.exe.
Is there a way to programmatically query the case sensitivity of a directory without running fsutil.exe or hackishly creating files with different casing to see if they collide?
I haven't really found any way to test this through research. I've read this is an actual NTFS attribute yet it doesn't show up when getting the file's attributes. I also noticed FindFirstFile will return the casing of the correct file if two different casings exist. Other than this I have no idea where to go as there really isn't a lot of information on this. This stuff is still pretty new.
As others have mentioned, making something case-sensitive is not a good idea in Windows due to comparability issues. I'm aware of that and my goal is to scan and work with existing case sensitive directories in the file system.
Progress:
I've discovered that Windows' FindFirstFile and friends functions respects the case sensitivity of the directory even without using the FIND_FIRST_EX_CASE_SENSITIVE. It will not return a file with invalid casing. Now I'm trying to figure out if there's a good way to make use of this.

Here is my P/Invoke solution thanks to the help of #eryksun's comment.
Edit 2: Added SetDirectoryCaseSensitive()
Edit 3: Added IsDirectoryCaseSensitivitySupported()
I've implemented the the native method NtQueryInformationFile while using the FILE_INFORMATION_CLASS FileCaseSensitiveInformation to read the FILE_CASE_SENSITIVE_INFORMATION structure.
public static partial class NativeMethods {
public static readonly IntPtr INVALID_HANDLE = new IntPtr(-1);
public const FileAttributes FILE_FLAG_BACKUP_SEMANTICS = (FileAttributes) 0x02000000;
public enum NTSTATUS : uint {
SUCCESS = 0x00000000,
NOT_IMPLEMENTED = 0xC0000002,
INVALID_INFO_CLASS = 0xC0000003,
INVALID_PARAMETER = 0xC000000D,
NOT_SUPPORTED = 0xC00000BB,
DIRECTORY_NOT_EMPTY = 0xC0000101,
}
public enum FILE_INFORMATION_CLASS {
None = 0,
// Note: If you use the actual enum in here, remember to
// start the first field at 1. There is nothing at zero.
FileCaseSensitiveInformation = 71,
}
// It's called Flags in FileCaseSensitiveInformation so treat it as flags
[Flags]
public enum CASE_SENSITIVITY_FLAGS : uint {
CaseInsensitiveDirectory = 0x00000000,
CaseSensitiveDirectory = 0x00000001,
}
[StructLayout(LayoutKind.Sequential)]
public struct IO_STATUS_BLOCK {
[MarshalAs(UnmanagedType.U4)]
public NTSTATUS Status;
public ulong Information;
}
[StructLayout(LayoutKind.Sequential)]
public struct FILE_CASE_SENSITIVE_INFORMATION {
[MarshalAs(UnmanagedType.U4)]
public CASE_SENSITIVITY_FLAGS Flags;
}
// An override, specifically made for FileCaseSensitiveInformation, no IntPtr necessary.
[DllImport("ntdll.dll")]
[return: MarshalAs(UnmanagedType.U4)]
public static extern NTSTATUS NtQueryInformationFile(
IntPtr FileHandle,
ref IO_STATUS_BLOCK IoStatusBlock,
ref FILE_CASE_SENSITIVE_INFORMATION FileInformation,
int Length,
FILE_INFORMATION_CLASS FileInformationClass);
[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Auto)]
public static extern IntPtr CreateFile(
[MarshalAs(UnmanagedType.LPTStr)] string filename,
[MarshalAs(UnmanagedType.U4)] FileAccess access,
[MarshalAs(UnmanagedType.U4)] FileShare share,
IntPtr securityAttributes, // optional SECURITY_ATTRIBUTES struct or IntPtr.Zero
[MarshalAs(UnmanagedType.U4)] FileMode creationDisposition,
[MarshalAs(UnmanagedType.U4)] FileAttributes flagsAndAttributes,
IntPtr templateFile);
[DllImport("kernel32.dll", SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool CloseHandle(
IntPtr hObject);
public static bool IsDirectoryCaseSensitive(string directory, bool throwOnError = true) {
// Read access is NOT required
IntPtr hFile = CreateFile(directory, 0, FileShare.ReadWrite,
IntPtr.Zero, FileMode.Open,
FILE_FLAG_BACKUP_SEMANTICS, IntPtr.Zero);
if (hFile == INVALID_HANDLE)
throw new Win32Exception();
try {
IO_STATUS_BLOCK iosb = new IO_STATUS_BLOCK();
FILE_CASE_SENSITIVE_INFORMATION caseSensitive = new FILE_CASE_SENSITIVE_INFORMATION();
NTSTATUS status = NtQueryInformationFile(hFile, ref iosb, ref caseSensitive,
Marshal.SizeOf<FILE_CASE_SENSITIVE_INFORMATION>(),
FILE_INFORMATION_CLASS.FileCaseSensitiveInformation);
switch (status) {
case NTSTATUS.SUCCESS:
return caseSensitive.Flags.HasFlag(CASE_SENSITIVITY_FLAGS.CaseSensitiveDirectory);
case NTSTATUS.NOT_IMPLEMENTED:
case NTSTATUS.NOT_SUPPORTED:
case NTSTATUS.INVALID_INFO_CLASS:
case NTSTATUS.INVALID_PARAMETER:
// Not supported, must be older version of windows.
// Directory case sensitivity is impossible.
return false;
default:
throw new Exception($"Unknown NTSTATUS: {(uint)status:X8}!");
}
}
finally {
CloseHandle(hFile);
}
}
}
Here is the implementation for setting the case sensitivity of a directory by implementing NTSetInformationFile. (Which has a parameter list that is identical to NTQueryInformationFile. Again, the problem was solved thanks to insight from #eryksun.
FILE_WRITE_ATTRIBUTES is a FileAccess flag that is not implemented in C#, so it needs to be defined and/or casted from the the value 0x100.
partial class NativeMethods {
public const FileAccess FILE_WRITE_ATTRIBUTES = (FileAccess) 0x00000100;
// An override, specifically made for FileCaseSensitiveInformation, no IntPtr necessary.
[DllImport("ntdll.dll")]
[return: MarshalAs(UnmanagedType.U4)]
public static extern NTSTATUS NtSetInformationFile(
IntPtr FileHandle,
ref IO_STATUS_BLOCK IoStatusBlock,
ref FILE_CASE_SENSITIVE_INFORMATION FileInformation,
int Length,
FILE_INFORMATION_CLASS FileInformationClass);
// Require's elevated priviledges
public static void SetDirectoryCaseSensitive(string directory, bool enable) {
// FILE_WRITE_ATTRIBUTES access is the only requirement
IntPtr hFile = CreateFile(directory, FILE_WRITE_ATTRIBUTES, FileShare.ReadWrite,
IntPtr.Zero, FileMode.Open,
FILE_FLAG_BACKUP_SEMANTICS, IntPtr.Zero);
if (hFile == INVALID_HANDLE)
throw new Win32Exception();
try {
IO_STATUS_BLOCK iosb = new IO_STATUS_BLOCK();
FILE_CASE_SENSITIVE_INFORMATION caseSensitive = new FILE_CASE_SENSITIVE_INFORMATION();
if (enable)
caseSensitive.Flags |= CASE_SENSITIVITY_FLAGS.CaseSensitiveDirectory;
NTSTATUS status = NtSetInformationFile(hFile, ref iosb, ref caseSensitive,
Marshal.SizeOf<FILE_CASE_SENSITIVE_INFORMATION>(),
FILE_INFORMATION_CLASS.FileCaseSensitiveInformation);
switch (status) {
case NTSTATUS.SUCCESS:
return;
case NTSTATUS.DIRECTORY_NOT_EMPTY:
throw new IOException($"Directory \"{directory}\" contains matching " +
$"case-insensitive files!");
case NTSTATUS.NOT_IMPLEMENTED:
case NTSTATUS.NOT_SUPPORTED:
case NTSTATUS.INVALID_INFO_CLASS:
case NTSTATUS.INVALID_PARAMETER:
// Not supported, must be older version of windows.
// Directory case sensitivity is impossible.
throw new NotSupportedException("This version of Windows does not support directory case sensitivity!");
default:
throw new Exception($"Unknown NTSTATUS: {(uint)status:X8}!");
}
}
finally {
CloseHandle(hFile);
}
}
}
Finally I have added a method to calculate once if the version of Windows supports case sensitive directories. This just creates a folder with a constant GUID name in Temp and checks the NTSTATUS result (so it can check a folder it knows it has access to).
partial class NativeMethods {
// Use the same directory so it does not need to be recreated when restarting the program
private static readonly string TempDirectory =
Path.Combine(Path.GetTempPath(), "88DEB13C-E516-46C3-97CA-46A8D0DDD8B2");
private static bool? isSupported;
public static bool IsDirectoryCaseSensitivitySupported() {
if (isSupported.HasValue)
return isSupported.Value;
// Make sure the directory exists
if (!Directory.Exists(TempDirectory))
Directory.CreateDirectory(TempDirectory);
IntPtr hFile = CreateFile(TempDirectory, 0, FileShare.ReadWrite,
IntPtr.Zero, FileMode.Open,
FILE_FLAG_BACKUP_SEMANTICS, IntPtr.Zero);
if (hFile == INVALID_HANDLE)
throw new Exception("Failed to open file while checking case sensitivity support!");
try {
IO_STATUS_BLOCK iosb = new IO_STATUS_BLOCK();
FILE_CASE_SENSITIVE_INFORMATION caseSensitive = new FILE_CASE_SENSITIVE_INFORMATION();
// Strangely enough, this doesn't fail on files
NTSTATUS result = NtQueryInformationFile(hFile, ref iosb, ref caseSensitive,
Marshal.SizeOf<FILE_CASE_SENSITIVE_INFORMATION>(),
FILE_INFORMATION_CLASS.FileCaseSensitiveInformation);
switch (result) {
case NTSTATUS.SUCCESS:
return (isSupported = true).Value;
case NTSTATUS.NOT_IMPLEMENTED:
case NTSTATUS.INVALID_INFO_CLASS:
case NTSTATUS.INVALID_PARAMETER:
case NTSTATUS.NOT_SUPPORTED:
// Not supported, must be older version of windows.
// Directory case sensitivity is impossible.
return (isSupported = false).Value;
default:
throw new Exception($"Unknown NTSTATUS {(uint)result:X8} while checking case sensitivity support!");
}
}
finally {
CloseHandle(hFile);
try {
// CHOOSE: If you delete the folder, future calls to this will not be any faster
// Directory.Delete(TempDirectory);
}
catch { }
}
}
}

Evaluate if drive is in use

I'd like to evaluate wether a drive is in use (if I'm not mistaken this means that some read/write stuff is happening with the drive) using C#. I wouldn't mind for a solution using bash scripts or similiar either, as I could use them in a C# application. I already found a question regarding bash scripts here, but couldn't solve my problem with the answers given.
I considered to use the DriveInfo class already, however it didn't seem to have anything useful for me. I wondered wether I could use the IsReady property from DriveInfo, because I guessed that it wouldn't be ready while it is read/written, but this attempt seems rather botchy to me.
However I still tried it:
private static bool IsDriveInUse ()
{
var drive = DriveInfo.GetDrives ().FirstOrDefault(info => info.Name.StartsWith(DRIVE_LETTER.ToString()));
return drive != null && !drive.IsReady;
}
But it didn't work (it returned false while I played music from my drive).
An optimal solution for me would be a function that tells me wether the drive was in use in a specific span of time (let's stick to the name IsDriveInUse). That means that if the time was for example 60 seconds, IsDriveInUse should return true if 5 seconds before the function call content from the drive was read and false if there was no read/write action in the passed 60 seconds.
EDIT To specify what exactly I mean by in use, I'll try to explain what I'm trying to do. I am writing a tool, which automatically spins down my hard drive, when it's been idle or when I press a keyboard shortcut. I managed to spin it down programmatically (even though either the windows integrated tool nor other tools I found were able to do that, but that's another problem). However, it now spins down the hard drive every minute, regardless of wether it's currently in use or not. That means, if I play music from my hard drive, it's still spinned down, just to spin up directly after it, which doesn't decrease noise development.
I hope this clarified the matter.
EDIT I now tried using the FSCTL_LOCK_VOLUME control code (I couldn't find a value for IOCTL_DISK_PERFORMANCE), but it still returned false for IsDriveInUse() while I was playing music. Furthermore it caused windows to directly spin the drive up again as I spinned it down (probably because the releasing made Windows think that something was using the drive). This is what I tried:
public class DriveManager
{
public const int FSCTL_LOCK_VOLUME = 0x00090018;
public const int FSCTL_UNLOCK_VOLUME = 0x0009001c;
[DllImport ("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern IntPtr CreateFile (
string lpFileName, uint dwDesiredAccess, uint dwShareMode, IntPtr lpSecurityAttributes,
uint dwCreationDisposition, uint dwFlagsAndAttributes, IntPtr hTemplateFile);
[return: MarshalAs (UnmanagedType.Bool)]
[DllImport ("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
public static extern bool DeviceIoControl (
[In] SafeFileHandle hDevice,
[In] int dwIoControlCode, [In] IntPtr lpInBuffer,
[In] int nInBufferSize, [Out] IntPtr lpOutBuffer,
[In] int nOutBufferSize, out int lpBytesReturned,
[In] IntPtr lpOverlapped);
public static SafeFileHandle CreateFileR (string device)
{
string str = device.EndsWith (#"\") ? device.Substring (0, device.Length - 1) : device;
return new SafeFileHandle (
CreateFile (#"\\.\" + str, WinntConst.GENERIC_READ, WinntConst.FILE_SHARE_READ, IntPtr.Zero,
WinntConst.OPEN_EXISTING, WinntConst.FILE_ATTRIBUTE_NORMAL, IntPtr.Zero), true);
}
internal class WinntConst
{
// Fields
internal static uint FILE_ATTRIBUTE_NORMAL = 0x80;
internal static uint FILE_SHARE_READ = 1;
internal static uint GENERIC_READ = 0x80000000;
internal static uint OPEN_EXISTING = 3;
}
public static bool IsDriveInUse (string deviceName)
{
var handle = CreateFileR (deviceName);
var buffer = Marshal.AllocHGlobal (sizeof (int));
try
{
return
DeviceIoControl (handle,
FSCTL_LOCK_VOLUME,
IntPtr.Zero,
0,
buffer,
sizeof(int),
out var bytesReturned,
IntPtr.Zero
);
}
finally
{
var sessionId = Marshal.ReadInt32 (buffer);
Marshal.FreeHGlobal (buffer);
handle.Close ();
}
}
And the implementation:
private static bool IsDriveInUse () => DriveManager.IsDriveInUse ($#"{DRIVE_LETTER}:\");
Maybe it helps to see the part in which I'm spinning the disc down as well (I used Smartmontools for this):
internal static class Program
{
private const string PROGRAM_PATH = #"External\smartctl.exe";
private const string ARGUMENTS_SHUTDOWN = #"-s standby,now {0}:";
private const char DRIVE_LETTER = 'd';
public static void Main (string [] args)
{
InitializeHotKey ();
Console.WriteLine ("Hotkey registered!");
while (true)
{
Thread.Sleep (60000);
if (!IsDriveInUse ())
ShutDownDrive (true);
}
}
private static bool IsDriveInUse () => DriveManager.IsDriveInUse ($#"{DRIVE_LETTER}:\");
private static void InitializeHotKey ()
{
HotKeyManager.RegisterHotKey (Keys.D, KeyModifiers.Alt | KeyModifiers.Control);
HotKeyManager.HotKeyPressed += HotKeyPressed;
}
private static void HotKeyPressed (object sender, HotKeyEventArgs hotKeyEventArgs) => ShutDownDrive (true);
private static void ShutDownDrive (bool withDialog = false)
{
Process process;
(process = new Process
{
StartInfo = new ProcessStartInfo
{
WindowStyle = ProcessWindowStyle.Hidden,
FileName = PROGRAM_PATH,
Arguments = string.Format (ARGUMENTS_SHUTDOWN, DRIVE_LETTER)
}
}).Start ();
process.WaitForExit ();
process.Close ();
if (withDialog)
Console.WriteLine ("Drive shut down!");
}
}

Perhaps you could use the Windows Performance Counter relevant to your drive ?
"Disk Read/sec" seems quite relevant for what youhave in mind.
In .Net, the counters are available via System.Diagnostics.PerformanceCounter
see there :
https://msdn.microsoft.com/en-us/library/system.diagnostics.performancecounter(v=vs.110).aspx

C#: How to tell if an EXE has an icon?

I'm looking for a way to tell whether or not an EXE file contains an application icon. From the answer here, I tried this:
bool hasIcon = Icon.ExtractAssociatedIcon(exe) != null;
But this seems to work even if the EXE has no icon. Is there a way to detect this in .NET?
edit: I'm OK with solutions involving P/Invoke.

You can get the IDI_APPLICATION icon through SystemIcons.Application property from SystemIcons class
if (Icon.ExtractAssociatedIcon(exe).Equals(SystemIcons.Application))
{
...
}
See MSDN for more details.

Try this. Define your pinvoke like this:
[DllImport("user32.dll")]
internal static extern IntPtr LoadImage(IntPtr hInst, IntPtr name, uint type, int cxDesired, int cyDesired, uint fuLoad);
[DllImport("kernel32.dll")]
static extern bool EnumResourceNames(IntPtr hModule, int dwID, EnumResNameProcDelegate lpEnumFunc, IntPtr lParam);
delegate bool EnumResNameProcDelegate(IntPtr hModule, IntPtr lpszType, IntPtr lpszName, IntPtr lParam);
[DllImport("kernel32.dll", SetLastError = true)]
internal static extern IntPtr LoadLibraryEx(string name, IntPtr handle, uint dwFlags);
private const int LOAD_LIBRARY_AS_DATAFILE = 0x00000002;
private const int LOAD_LIBRARY_AS_IMAGE_RESOURCE = 0x00000020;
private const int IMAGE_ICON = 1;
private const int RT_GROUP_ICON = 14;
Then you can write a function like this:
static bool HasIcon(string path)
{
// This loads the exe into the process address space, which is necessary
// for LoadImage / LoadIcon to work note, that LOAD_LIBRARY_AS_DATAFILE
// allows loading a 32-bit image into 64-bit process which is otherwise impossible
IntPtr moduleHandle = LoadLibraryEx(path, IntPtr.Zero, LOAD_LIBRARY_AS_DATAFILE | LOAD_LIBRARY_AS_IMAGE_RESOURCE);
if (moduleHandle == IntPtr.Zero)
{
throw new ApplicationException("Cannot load executable");
}
IntPtr index = IntPtr.Zero;
bool hasIndex = false;
bool enumerated = EnumResourceNames(moduleHandle, RT_GROUP_ICON, (module, type, name, param) =>
{
index = name;
hasIndex = true;
// Only load first icon and bail out
return false;
}, IntPtr.Zero);
if (!enumerated || !hasIndex)
{
return false;
}
// Strictly speaking you do not need this you can return true now
// This is to demonstrate how to access the icon that was found on
// the previous step
IntPtr result = LoadImage(moduleHandle, index, IMAGE_ICON, 0, 0, 0);
if (result == IntPtr.Zero)
{
return false;
}
return true;
}
It has added bonus that if you want to, after LoadImage you can load the icon with
Icon icon = Icon.FromHandle(result);
and do whatever you want with that.
Important note: I have not done any clean up in the function, so you cannot use it as is, you'll leak handles/memory. Proper clean up is left as an exercise for the reader. Read the description of every of the winapi function used in MSDN and call corresponding clean up functions as needed.
An alternate way using shell32 api can be found here, although I don't know if it has the same problem you encountered.
Also, old, but still very relevant article: https://msdn.microsoft.com/en-us/library/ms997538.aspx

Is it possible to determine the file name of a certificate's private key on a remote Windows server?

I'm trying to determine the file name of a certificate's private key stored on a remote Windows (2k3/2k8) machine and am having some difficulty. I'm also not that familiar with Microsoft's CryptAPI, so I'm looking for any help you can provide.
The purpose of this exercise is to find certificates with private keys installed on a remote computer that meet a specific criteria and ensure the correct rights are assigned to their private key files. Although I could assign rights at the folder level, I'd prefer to only assign rights at the private key file level where it's necessary (for obvious reasons).
Here's the scenario, assume a service account with administrative-like permissions is accessing the certificate store:
I retreive the remote certificate store using the following call from C# using p/invoke:
[DllImport("CRYPT32", EntryPoint = "CertOpenStore", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern IntPtr CertOpenStore(int storeProvider, int encodingType, int hcryptProv, int flags, string pvPara);
IntPtr storeHandle = CertOpenStore(CERT_STORE_PROV_SYSTEM,
0,
0,
CERT_SYSTEM_STORE_LOCAL_MACHINE,
string.Format(#"\{0}{1}", serverName, name));
I then use CertEnumCertificatesInStore to retreive certificates that I want to evaluate.
[DllImport("CRYPT32", EntryPoint = "CertEnumCertificatesInStore", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern IntPtr CertEnumCertificatesInStore(IntPtr storeProvider, IntPtr prevCertContext);
IntPtr certCtx = IntPtr.Zero;
certCtx = CertEnumCertificatesInStore(storeHandle, certCtx);
If a certificate matches my criteria, I create an X509Certificate2 instance from the IntPtr returned from the CertEnumCertificatesInStore call like:
X509Certificate2 current = new X509Certificate2(certCtx);
Once I have the X509Certificate2 instances for certificates I'm interested in, I call CryptAcquireCertificatePrivateKey to get the private key provider:
[DllImport("crypt32", CharSet = CharSet.Unicode, SetLastError = true)]
internal extern static bool CryptAcquireCertificatePrivateKey(IntPtr pCert, uint dwFlags, IntPtr pvReserved, ref IntPtr phCryptProv, ref int pdwKeySpec, ref bool pfCallerFreeProv);
//cert is an X509Certificate2
CryptAcquireCertificatePrivateKey(cert.Handle,
0,
IntPtr.Zero,
ref hProvider,
ref _keyNumber,
ref freeProvider);
To retreive the private key file name, I try to request the Unique Container Name from the hProvider as pData like:
[DllImport("advapi32", CharSet = CharSet.Unicode, SetLastError = true)]
internal extern static bool CryptGetProvParam(IntPtr hCryptProv, CryptGetProvParamType dwParam, IntPtr pvData, ref int pcbData, uint dwFlags);
IntPtr pData = IntPtr.Zero;
CryptGetProvParam(hProvider, PP_UNIQUE_CONTAINER, pData, ref cbBytes, 0));
So far all of the above steps work great locally (servername == local machine name); however, the unique container name (private key filename) that's returned for a certificate stored in a remote computer's local machine certificate store doesn't render as the actual private key filename I'm seeing under:
w2k3: \Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys
ws08: \ProgramData\Microsoft\Crypto\RSA\MachineKeys
For example, if I run the above steps directly on the remote machine, I get a private key file name AAAAAAA-111111, but if I run them remotely, I get a private key BBBBBBBB-2222222. Also, if I install the remote certificate locally and run the steps against my local machine I get the same private key name BBBBBBBB-2222222.
Most likely I feel that I may be missing a caveat in step 4, calling CryptAcquireCertificatePrivateKey. It may be that this call relies on the local machine's identity to generate the name of the unique container that would be used to store the private key blob.
Updated
After some further research, I found a blog that details out exactly how the filenames for private key containers are created here.
Instead of using CryptAcquireCertificatePrivateKey, you can use the methods described on that blog to get the private key container name on any machine once you have the name of the container obtained by CertGetCertificateContextProperty. The code here shows how to get the private key container name so you can generate the private key filename. * disclaimer - I'm pretty sure this is subject to change and may not even be complete, but am posting it in case it helps someone else in the future *
Structs and P/Invoke:
[StructLayout(LayoutKind.Sequential)]
public struct CryptKeyProviderInfo
{
[MarshalAs(UnmanagedType.LPWStr)]
public String pwszContainerName;
[MarshalAs(UnmanagedType.LPWStr)]
public String pwszProvName;
public uint dwProvType;
public uint dwFlags;
public uint cProvParam;
public IntPtr rgProvParam;
public uint dwKeySpec;
}
public const uint CERT_KEY_PROV_INFO_PROP_ID = 0x00000002;
[DllImport("crypt32.dll", SetLastError = true)]
internal extern static bool CertGetCertificateContextProperty(IntPtr pCertContext, uint dwPropId, IntPtr pvData, ref uint pcbData);
IntPtr providerInfo = IntPtr.Zero;
string containerName = string.Empty;
try
{
//Win32 call w/IntPtr.Zero will get the size of our Cert_Key_Prov_Info_Prop_ID struct
uint pcbProviderInfo = 0;
if (!Win32.CertGetCertificateContextProperty(certificate.Handle, Win32.CERT_KEY_PROV_INFO_PROP_ID, IntPtr.Zero, ref pcbProviderInfo))
{
//if we can't get the certificate context, return string.empty
return string.Empty;
}
//Allocate heap for Cert_Key_Prov_Info_Prop_ID struct
providerInfo = Marshal.AllocHGlobal((int)pcbProviderInfo);
//Request actual Cert_Key_Prov_Info_Prop_ID struct with populated data using our allocated heap
if (Win32.CertGetCertificateContextProperty(certificate.Handle, Win32.CERT_KEY_PROV_INFO_PROP_ID, providerInfo, ref pcbProviderInfo))
{
//Cast returned pointer into managed structure so we can refer to it by it's structure layout
Win32.CryptKeyProviderInfo keyInfo = (Win32.CryptKeyProviderInfo)Marshal.PtrToStructure(providerInfo, typeof(Win32.CryptKeyProviderInfo));
//Get the container name
containerName = keyInfo.pwszContainerName;
}
//Do clean-up immediately if possible
if (providerInfo != IntPtr.Zero)
{
Marshal.FreeHGlobal(providerInfo);
providerInfo = IntPtr.Zero;
}
}
finally
{
//Do clean-up on finalizer if an exception cause early terminiation of try - after alloc, before cleanup
if (providerInfo != IntPtr.Zero)
Marshal.FreeHGlobal(providerInfo);
}

Using the CertGetCertificateContextProperty above, I was able to solve this question. So it is possible to determine the file name of a certificate's private key on a remote computer using the steps mentioned in the update.

Programmatically install Certificate Revocation List (CRL)

I need to download and install about 50 CRLs once a week and install them on several Windows servers. Downloading is the easy part, is there a way I could script the CRL import process?

Here is my final source (slightly scrubbed for the public) - but should work. I won't change the accepted answer, but I do hope this helps (as does upvoting the question and answers!).
Note: This will import both a CRL or a regular certificate into the LOCAL MACHINE Trusted Root store. Changing the below CERT_SYSTEM_STORE_LOCAL_MACHINE to CERT_SYSTEM_STORE_CURRENT_USER in the call CertOpenStore will change it to work for the Current User store.
using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;
namespace ConsoleApplication2
{
class Program
{
public struct CRYPTUI_WIZ_IMPORT_SRC_INFO
{
public Int32 dwSize;
public Int32 dwSubjectChoice;
[MarshalAs(UnmanagedType.LPWStr)]public String pwszFileName;
public Int32 dwFlags;
[MarshalAs(UnmanagedType.LPWStr)]public String pwszPassword;
}
[DllImport("CryptUI.dll", CharSet = CharSet.Auto, SetLastError = true)]
public static extern Boolean CryptUIWizImport(
Int32 dwFlags,
IntPtr hwndParent,
IntPtr pwszWizardTitle,
ref CRYPTUI_WIZ_IMPORT_SRC_INFO pImportSrc,
IntPtr hDestCertStore
);
[DllImport("CRYPT32.DLL", CharSet = CharSet.Auto, SetLastError = true)]
public static extern IntPtr CertOpenStore(
int storeProvider,
int encodingType,
IntPtr hcryptProv,
int flags,
String pvPara
);
public const Int32 CRYPTUI_WIZ_IMPORT_SUBJECT_FILE = 1;
public const Int32 CRYPT_EXPORTABLE = 0x00000001;
public const Int32 CRYPT_USER_PROTECTED = 0x00000002;
public const Int32 CRYPTUI_WIZ_NO_UI = 0x0001;
private static int CERT_STORE_PROV_SYSTEM = 10;
private static int CERT_SYSTEM_STORE_CURRENT_USER = (1 << 16);
private static int CERT_SYSTEM_STORE_LOCAL_MACHINE = (2 << 16);
static void Main(string[] args)
{
if (args.Length != 1)
{
Console.WriteLine("Usage: certimp.exe list.crl");
Environment.ExitCode = 1;
}
else
{
IntPtr hLocalCertStore = CertOpenStore(
CERT_STORE_PROV_SYSTEM,
0,
IntPtr.Zero,
CERT_SYSTEM_STORE_LOCAL_MACHINE,
"ROOT"
);
CRYPTUI_WIZ_IMPORT_SRC_INFO importSrc = new CRYPTUI_WIZ_IMPORT_SRC_INFO();
importSrc.dwSize = Marshal.SizeOf(importSrc);
importSrc.dwSubjectChoice = CRYPTUI_WIZ_IMPORT_SUBJECT_FILE;
importSrc.pwszFileName = args[0];
importSrc.pwszPassword = null;
importSrc.dwFlags = CRYPT_EXPORTABLE | CRYPT_USER_PROTECTED;
if (!CryptUIWizImport(
CRYPTUI_WIZ_NO_UI,
IntPtr.Zero,
IntPtr.Zero,
ref importSrc,
hLocalCertStore
))
{
Console.WriteLine("CryptUIWizImport error " + Marshal.GetLastWin32Error());
Environment.ExitCode = -1;
}
}
}
}
}

I don't know a way to do it via script.
Can you write C code? If I understand what you want to do, you will use the CryptUiWizImport function, and the CRYPTUI_WIZ_IMPORT_SRC_INFO structure.
Here's a sample of code that installs a Cert; the corresponding CRL import is similar.
Addendum:
This post points out that Win32 APIs (such as CryptUiWizImport) are not directly accessible from PowerShell, and then describes a possible workaround: from within the PowerShell script, dynamically generate and compile C# code that does the P/Invoke stuff, and then run the resulting assembly. This would allow you to do the CryptUiWizImport strictly from a powershell script, although it would be a pretty exotic one.

Hm. Is there any reason not to use the certutil.exe utility? I can import a Certificate Revocation List into the appropriate store by running the following command:
certutil -addstore CA <FileName>.crl

In Powershell there is a Cert: provider which represents the certificate store. Manipulating it is done via the standard cmdlets so you might be able to integrate a revocation list there somewhere. I just don't know enough about how Windows handles certificates to be of any further help here.

We have to use only Win32 Apis to do this. There is no firstclass C# system APIs to do this. Refer https://stackoverflow.com/a/67814697/3671594