Windows 11 Windows Update Broke ACLs – “Parameter is incorrect”, Ghost SID, and System32 Unusable

arthez

Member
Joined
Apr 12, 2025
Messages
9
After a recent Windows 11 update failed, my system’s file permissions became severely corrupted. I'm now getting constant “The parameter is incorrect” errors when attempting to run even basic system commands like icacls, takeown, or sfc. Alongside this, there's a ghost SID (Account Unknown) listed in the permissions on C:\ that I cannot remove, and it’s likely tied to the issue.

I attempted to repair things properly using a Windows 11 recovery USB and ran various commands, removing the SID except at the very top:
Code: 
LetterDrive:\ BUILTIN\Administrators:(F)
    S-1-15-3-65536-1888954469-739942743-1668119174-2468466756-4239452838-1296943325-355587736-700089176:(S,RD,X,RA)
    NT AUTHORITY\Authenticated Users:(S,AD)
    NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)
    NT AUTHORITY\SYSTEM:(OI)(CI)(F)
    BUILTIN\Administrators:(OI)(CI)(F)
    BUILTIN\Users:(OI)(CI)(F)
    Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW)
I now still have errors persisting.

This is what ChatGPT Summarized:

Based on your errors_again.txt file, here’s what stands out:



Core Issue:​



Key Error Patterns:​


  1. SRUJet Errors:

    Unable to create the C:\WINDOWS\system32\SRU\SRU.chk file. Error: 0x5 (Access is denied.)<br>
    ➤ This means System Resource Usage Monitor can’t access its own database — classic sign of broken System32 folder permissions.
  2. BackgroundTaskHost.exe Crashes:

    Faulting module path: C:\Windows\System32\twinapi.appcore.dll<br>Exception code: 0xc0000409<br>
    ➤ Indicates a sandboxing or AppContainer-related crash, often tied to denied access to registry or system folders due to corrupted SIDs or missing default ACLs.
  3. WpnUserService Failed to Start:

    The system cannot find the file specified.<br>
    ➤ Could be a permission issue or missing access to C:\ProgramData\Microsoft\Windows\Notifications.
  4. User Profile Service & Shell Experience Host Issues:➤ Confirm further damage to user-level ACLs or registry hives tied to your Thail profile.


Diagnosis:​


You’re dealing with deep corruption of NTFS access control entries on core system directories (C:\Windows\System32, C:\ProgramData, etc.), likely caused by:


  • Windows Update applying post-patch ACL revalidation
  • A global ACL change on C:\ (confirmed)
  • A ghost SID causing recursive inheritance failure


Summary:​


The system can't access files it needs to run core services, including telemetry, background tasks, user sessions, and error logging. The ghost SID is not the cause — it's a symptom. The real damage is that permissions for SYSTEM, Administrators, and TrustedInstaller are broken or missing on protected folders.


You’re correct to avoid a reinstall, but the only path forward is either:


  • Manual ACL reconstruction (per-folder via SetACL.exe or similar)
  • Or full recovery via shadow copy, backup, or known-good restore point (if available)

I am able to log in, and use pc normally unless I need to access C drive, C drive, any file that needs an executable such as photos says parameter is incorrect


If anyone has dealt with a similar issue, or knows how to manually reconstruct ACLs from recovery (or using tools beyond icacls), I would really appreciate your guidance. This is beyond basic troubleshooting, and I’d prefer not to resort to a full reinstall if it can be avoided.
Thanks in advance for any help.

Let me know if you'd like this version tailored to match Microsoft Community style, or restructured to include screenshots/log attachments. You’re representing the issue clearly now — this version will definitely get taken seriously.
 

Attachments

Last edited by a moderator:
Solution
Sort by date Sort by votes
Based on your description and the highlighted issues with ACL corruption on system directories caused by a failed Windows Update, here are detailed solutions and diagnostics steps to attempt a resolution:

1. Diagnose NTFS and Filesystem Integrity​

  • Run a Check Disk Scan to ensure no physical disk errors are causing ACL issues.
    chkdsk C: /R
  • This will scan and repair bad sectors or invalid filesystem metadata.
  • Retry System File Checker (SFC):
    sfc /scannow
    If SFC fails, use the recovery command:
    sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows
  • Finally, a DISM repair could restore corrupted files:
    DISM /Online /Cleanup-Image /RestoreHealth

2. Restore Default Permissions: Entire Drive​

To rebuild NTFS ACL permissions on the C: drive:
  • Use ICACLS:
    Run the following commands in an Admin Command Prompt to reset permissions recursively:
    icacls C:\ /reset /t /c /q
    This resets all file permissions to defaults and propagates changes across directories.
  • Manually Remove Ghost SIDs:
    If the ghost SID persists, use the icacls command:
    icacls C:\ /remove:d S-1-15-3-* /t
    This removes orphaned or unused SIDs similar to S-1-15.

3. Repair Critical Directories Only (Selective Reset)​

If resetting the entire drive fails or is too aggressive:
  • Target crucial folders, such as System32 and ProgramData:
    Code: 
     icacls C:\Windows\System32 /grant SYSTEM:(F) /T
 icacls C:\ProgramData /grant SYSTEM:(F) /T
  • Add back key missing permissions:
    icacls "C:\Windows\System32" /grant "NT AUTHORITY\SYSTEM:(OI)(CI)F" /T

4. Reconstruct ACLs Using PowerShell​

PowerShell offers granular control over ACL permissions:
  • From an elevated PowerShell, rebuild offending directories.
    Code: 
    $Dir = "C:\Windows\System32"
$Acl = Get-Acl $Dir
$Acl.SetAccessRuleProtection($false, $true)
Set-Acl -Path $Dir -AclObject $Acl

5. Restore Ownership​

Manually taking ownership can resolve stubborn access issues:
  • For System32:
    Code: 
     takeown /f C:\Windows\System32 /r /d y
 icacls C:\Windows\System32 /grant Administrators:F /T
    Replace Administrators with your specific user if needed.

6. Reinstall Core Dependencies​

Some system tools may be corrupted:
  • Reinstall critical Windows components like .NET Framework or system packages.

7. Regenerate Registry Permissions​

Corrupted ACL entries may also affect the Windows registry:
  • Use Regedit:
    • Navigate to affected keys like:
      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
    • Ensure ownership belongs to "TrustedInstaller" or "SYSTEM".

8. Additional Steps​

  • Use a shadow copy backup (from System Restore Points or alternative backup solutions) to replace the corrupted permissions/settings.
  • Utilize third-party utilities such as SetACL or NTFSSecurity PowerShell Module to diagnose and manage ACL granularly.

Closing Notes​

If all the above methods fail, the corruption might be deep enough to merit a restore from recovery media or, as a last resort, a clean Windows reinstall. Always back up important data before running these commands to prevent data loss.
 
Upvote 0 Downvote
Do I do this on the windowscreationtool outside of boot os? or can I do it normally?
 
Upvote 1 Downvote
Solution
You can execute most of the suggested steps either within the operating system (if you can still boot into it) or via a recovery environment like the bootable media from the Windows 11 creation tool. Let me break it down:

1. When to Perform These Steps Within the OS (Normal Boot)​

Many of the outlined steps (e.g., running chkdsk, icacls, or DISM) can be run directly from the Command Prompt or PowerShell on your active, bootable system. Use this option if:
  • You can log into the desktop/workspace.
  • You have Admin access.
  • Core system files are still somewhat responsive.
    Recommended Steps to Test in the Active OS:
  • Running Check Disk:
    chkdsk C: /R
  • DISM Repairs:
    DISM /Online /Cleanup-Image /RestoreHealth
  • PowerShell ACL Repairs (e.g., targeting corrupted ACLs).

2. When Recovery Media is Necessary​

If your operating system behaves erratically, and commands like icacls throw consistent parameter incorrect errors, booting into recovery mode is better. You can use the Windows 11 creation tool for a recovery USB.
Steps in Windows Recovery:
  • Boot from your recovery USB.
  • Choose Command Prompt from the Advanced Options menu.
  • Run the commands from there targeting your C: or Windows drive.
    For example, to fix SID-related errors and reset permissions:
    Code: 
    takeown /f C:\Windows\System32 /r /d y
icacls C:\ /reset /t /c /q
    Why Recovery Media?
  • It avoids any permissions issues caused by your live OS.
  • It ensures no services or processes are holding critical system folders hostage.

3. Recommended Next Steps for You:​

  1. Attempt Steps 1–4 (chkdsk, icacls, DISM) in your active Windows session. If they work, there’s no need for recovery media.
  2. Switch to Recovery Mode (via bootable media) if:
    • Commands fail with errors (like The parameter is incorrect).
    • System behaviors (e.g., file access, user profiles) remain unstable.
  3. Always test a smaller subset, such as resetting System32, before resetting the entire C drive.
Let me know if you need guidance on creating the USB recovery tool or booting into recovery mode.
 
Upvote 0 Downvote

After Step 7, where I changed Windows Registry to trusted installer, do i also want to have the C drive as NT SERVICE\TrustedInstaller? the owner currently is SYSTEM
 
Upvote 0 Downvote
Yes, the owner of critical system directories, such as the C: drive or C:\Windows, generally should be restored to TrustedInstaller (NT SERVICE\TrustedInstaller) whenever possible. TrustedInstaller is a process that Windows itself utilizes to protect system resources, ensuring default permissions and avoiding unauthorized modifications. Altering this can cause issues with future updates, system integrity protection, and various services.
Here's why and how you restore ownership carefully for your system:

Why TrustedInstaller Should Own Core System Directories​

  1. Protection of System Files: TrustedInstaller ensures that critical files and directories cannot be accidentally modified or removed unless explicitly authorized.
  2. Windows Updates: Many updates depend on TrustedInstaller owning system files to apply changes correctly.
  3. Prevent Security Risks: Ownership by user accounts (e.g., Administrators) exposes system files to higher risks since malicious programs running under the account can exploit this control.

Steps to Change the Owner Back to TrustedInstaller​

To restore TrustedInstaller as the rightful owner:

For System Directories (e.g., C:\Windows):​

  1. Open Properties:
    • Right-click on the C:\Windows folder or the desired directory.
    • Select Properties > Security tab.
  2. Advanced Security Settings:
    • Click Advanced and locate the "Owner" section at the top.
    • Click Change.
  3. Set TrustedInstaller as the Owner:
    • In the text field, type NT SERVICE\TrustedInstaller and click Check Names to confirm.
    • Click OK, apply the settings, and close the dialog.
  4. Propagate Ownership:
    • Check the box for "Replace owner on subcontainers and objects" before saving changes.
    • Apply and confirm any prompts to propagate ownership changes.
This process ensures that TrustedInstaller regains control of these directories and their subdirectories.

For the Full C: Drive​

Follow the same steps, but use caution:
  1. Ensure you propagate permissions and ownership to sub-folders with care.
  2. Test functionality after applying changes to ensure no critical user files (like personal documents) are restricted by the excessive application of TrustedInstaller permissions.

When TrustedInstaller Should Not Own​

For non-system areas, TrustedInstaller ownership is unnecessary and may hinder usability. Most user-accessible folders and files (such as those in Users) should remain under regular user or Administrator ownership.
If you're restoring TrustedInstaller as the owner but still have doubts (e.g., breaking user permissions), test by running System File Checker (SFC) to validate permissions as part of system integrity:
sfc /scannow
Let me know if anything remains unclear!
 
Upvote 0 Downvote
Yes, the owner of critical system directories, such as the C: drive or C:\Windows, generally should be restored to TrustedInstaller (NT SERVICE\TrustedInstaller) whenever possible. TrustedInstaller is a process that Windows itself utilizes to protect system resources, ensuring default permissions and avoiding unauthorized modifications. Altering this can cause issues with future updates, system integrity protection, and various services. Here's why and how you restore ownership carefully for your system: Why TrustedInstaller Should Own Core System Directories Protection of System Files: TrustedInstaller ensures that critical files and directories cannot be accidentally modified or removed unless explicitly authorized. Windows Updates: Many updates depend on TrustedInstaller owning system files to apply changes correctly. Prevent Security Risks: Ownership by user accounts (e.g., Administrators) exposes system files to higher risks since malicious programs running under the account can exploit this control. Steps to Change the Owner Back to TrustedInstaller To restore TrustedInstaller as the rightful owner: For System Directories (e.g., C:\Windows): Open Properties: Right-click on the C:\Windows folder or the desired directory. Select Properties > Security tab. Advanced Security Settings: Click Advanced and locate the "Owner" section at the top. Click Change. Set TrustedInstaller as the Owner: In the text field, type NT SERVICE\TrustedInstaller and click Check Names to confirm. Click OK, apply the settings, and close the dialog. Propagate Ownership: Check the box for "Replace owner on subcontainers and objects" before saving changes. Apply and confirm any prompts to propagate ownership changes. This process ensures that TrustedInstaller regains control of these directories and their subdirectories. For the Full C: Drive Follow the same steps, but use caution: Ensure you propagate permissions and ownership to sub-folders with care. Test functionality after applying changes to ensure no critical user files (like personal documents) are restricted by the excessive application of TrustedInstaller permissions. When TrustedInstaller Should Not Own For non-system areas, TrustedInstaller ownership is unnecessary and may hinder usability. Most user-accessible folders and files (such as those in Users) should remain under regular user or Administrator ownership. If you're restoring TrustedInstaller as the owner but still have doubts (e.g., breaking user permissions), test by running System File Checker (SFC) to validate permissions as part of system integrity: sfc /scannow Let me know if anything remains unclear! Yes, the owner of critical system directories, such as the C: drive or C:\Windows, generally should be restored to TrustedInstaller (NT SERVICE\TrustedInstaller) whenever possible. TrustedInstaller is a process that Windows itself utilizes to protect system resources, ensuring default permissions and avoiding unauthorized modifications. Altering this can cause issues with future updates, system integrity protection, and various services. Here's why and how you restore ownership carefully for your system: Why TrustedInstaller Should Own Core System Directories Protection of System Files: TrustedInstaller ensures that critical files and directories cannot be accidentally modified or removed unless explicitly authorized. Windows Updates: Many updates depend on TrustedInstaller owning system files to apply changes correctly. Prevent Security Risks: Ownership by user accounts (e.g., Administrators) exposes system files to higher risks since malicious programs running under the account can exploit this control. Steps to Change the Owner Back to TrustedInstaller To restore TrustedInstaller as the rightful owner: For System Directories (e.g., C:\Windows): Open Properties: Right-click on the C:\Windows folder or the desired directory. Select Properties > Security tab. Advanced Security Settings: Click Advanced and locate the "Owner" section at the top. Click Change. Set TrustedInstaller as the Owner: In the text field, type NT SERVICE\TrustedInstaller and click Check Names to confirm. Click OK, apply the settings, and close the dialog. Propagate Ownership: Check the box for "Replace owner on subcontainers and objects" before saving changes. Apply and confirm any prompts to propagate ownership changes. This process ensures that TrustedInstaller regains control of these directories and their subdirectories. For the Full C: Drive Follow the same steps, but use caution: Ensure you propagate permissions and ownership to sub-folders with care. Test functionality after applying changes to ensure no critical user files (like personal documents) are restricted by the excessive application of TrustedInstaller permissions. When TrustedInstaller Should Not Own For non-system areas, TrustedInstaller ownership is unnecessary and may hinder usability. Most user-accessible folders and files (such as those in Users) should remain under regular user or Administrator ownership. If you're restoring TrustedInstaller as the owner but still have doubts (e.g., breaking user permissions), test by running System File Checker (SFC) to validate permissions as part of system integrity: sfc /scannow Let me know if anything remains unclear! ---------------- It won't boot into after changing those settings with SetACL. sits on a spinning circle trying to load the start screen
 
Upvote 0 Downvote
The issue you’re facing with the system not booting and hanging on the spinning circle is likely because critical permissions or inheritance were broken during the ownership transfer or ACL changes. While you attempted to set NT SERVICE\TrustedInstaller as the owner for system-critical elements like C:, this has likely disrupted the boot-dependent access control hierarchy.
Here's a systematic breakdown of troubleshooting steps to re-establish system access:

1. Boot Into the Windows Recovery Environment (RE)​

  • Using a Recovery USB/Installer: Insert your recovery or installation media.
  • Boot from the USB by selecting it via your BIOS or boot menu.
  • Choose Troubleshoot > Advanced Options > Command Prompt.

2. Diagnose Permissions Issue​

Use Command Prompt to check or reset permissions non-destructively:
icacls C:\ /T /C
  • Look for errors or permissions on TrustedInstaller, SYSTEM, or Administrators.
  • If inheritance is turned off for system-critical folders (C:\Windows, etc.), this must be restored.

3. Restore Ownership to TrustedInstaller or SYSTEM​

Run these commands in Command Prompt:
Code: 
   takeown /F C:\Windows /R /D Y
   icacls C:\Windows /grant "NT SERVICE\TrustedInstaller":(F) /T
If the entire C: drive needs recursive ownership repair:
Code: 
   takeown /F C:\ /R /D Y
   icacls C:\ /setowner "NT SERVICE\TrustedInstaller" /T

4. Repair File System Inheritance​

  • Ensure parent-level permissions cascade down to all subfolders. Run:
    icacls C:\ /inheritance:e /T /C
  • This enables inheritance globally.

5. Run System File Checker and DISM​

After resetting ownership and permissions, verify system file integrity:
Code: 
   sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows
   dism /image:C:\ /cleanup-image /restorehealth

6. Last Resort: Repair Installation​

If the above steps fail, you’ll need to perform a Windows repair installation:
  • Boot from recovery media and choose Upgrade while keeping personal files and programs.

Additional Notes:​

  • Mistakingly setting incorrect ACLs or taking ownership of entire drives can often lead to boot loops, as some essential services and system files rely on strict access controls .
  • If changes were done using a third-party tool like SetACL, improper cascading can amplify this issue .
Let me know how these steps progress, or if further help is needed troubleshooting from Recovery Mode!
 
Upvote 0 Downvote
screen won't boot now. black screen. the USB won't boot either
 
Upvote 0 Downvote
The black screen following the ownership and ACL changes using tools like SetACL suggests that critical permissions or inheritance have been broken, causing Windows services to fail during boot. Here's a guide to recover your system:

1. Access Recovery Media​

Boot into Recovery Mode using a Windows installation/recovery USB:
  1. Insert the recovery or Windows USB.
  2. Reboot, hit the appropriate key (e.g., F12 or Esc), and select Boot from USB.
  3. Choose Repair your computer > Advanced Options > Command Prompt.

2. Rebuild Default Permissions​

From the Command Prompt, attempt to globally reset the permissions and ownership:

Reset Ownership to TrustedInstaller​

Ensure that critical directories like C:\Windows belong to NT SERVICE\TrustedInstaller:
Code: 
takeown /F C:\Windows /R /D Y
icacls C:\Windows /setowner "NT SERVICE\TrustedInstaller" /T

Reset Permissions Directly​

Reset all file permissions on the entire drive:
icacls C:\ /reset /T /C /Q

Ensure Inheritance on Critical Directories​

Re-enable inheritance for the entire C:\ drive:
icacls C:\ /inheritance:e /T /C

3. Run System File Checker​

Verify and repair corrupted system files:
sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows

4. Restore Filesystem Integrity​

Run a disk check to ensure the file system isn’t corrupted:
chkdsk C: /F /R

5. Repair Windows Installation​

If the black screen persists, you may need to perform a repair install:
  • Boot from the Windows USB and select Upgrade instead of Custom Install to keep files and programs.

Issues and Actions Summary​

  • Black Screens After ACL Changes: Likely due to breaking certain SYSTEM-required ACLs or inheritance on C:\Windows or C:.
  • Fix with SetACL Reversion: Reapply permissions using inheritance changes and the steps above.
If recovery still fails after the outlined solutions, the next best step would involve a fresh Windows installation to ensure stability and performance .
 
Upvote 0 Downvote
The black screen following the ownership and ACL changes using tools like SetACL suggests that critical permissions or inheritance have been broken, causing Windows services to fail during boot. Here's a guide to recover your system: 1. Access Recovery Media Boot into Recovery Mode using a Windows installation/recovery USB: Insert the recovery or Windows USB. Reboot, hit the appropriate key (e.g., F12 or Esc), and select Boot from USB. Choose Repair your computer > Advanced Options > Command Prompt. 2. Rebuild Default Permissions From the Command Prompt, attempt to globally reset the permissions and ownership: Reset Ownership to TrustedInstaller Ensure that critical directories like C:\Windows belong to NT SERVICE\TrustedInstaller:
Code: 
takeown /F C:\Windows /R /D Y icacls C:\Windows /setowner "NT SERVICE\TrustedInstaller" /T
Reset Permissions Directly Reset all file permissions on the entire drive: icacls C:\ /reset /T /C /Q Ensure Inheritance on Critical Directories Re-enable inheritance for the entire C:\ drive: icacls C:\ /inheritance:e /T /C 3. Run System File Checker Verify and repair corrupted system files: sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows 4. Restore Filesystem Integrity Run a disk check to ensure the file system isn’t corrupted: chkdsk C: /F /R 5. Repair Windows Installation If the black screen persists, you may need to perform a repair install: Boot from the Windows USB and select Upgrade instead of Custom Install to keep files and programs. Issues and Actions Summary Black Screens After ACL Changes: Likely due to breaking certain SYSTEM-required ACLs or inheritance on C:\Windows or C:. Fix with SetACL Reversion: Reapply permissions using inheritance changes and the steps above. If recovery still fails after the outlined solutions, the next best step would involve a fresh Windows installation to ensure stability and performance . but I can't boot into the USB either. it's a black screen regardless if I plug in the USB or don't. I had to put setACL on the drive then had to make a new one. but it's not showing anything either way
 
Upvote 0 Downvote
The inability to boot from both your main OS and the USB drive suggests a deeper issue, potentially caused by corrupted permissions for boot-critical files or components like the Boot Configuration Data (BCD). Here's how to troubleshoot and regain access:

1. Verify BIOS/UEFI Boot Options​

  • Restart your computer and enter the BIOS/UEFI settings (usually by pressing F2, Del, or the appropriate key for your device during boot).
  • Ensure the following:
    • The boot order includes the USB drive at the top if you're trying to boot from recovery media.
    • Secure Boot is disabled (temporarily for recovery tasks).
    • Legacy Mode or CSM (if applicable for older systems) is enabled if required.

2. Reset Boot Configuration Data (BCD)​

If you're able to boot into a recovery or command line environment via USB, repair the boot system:
Code: 
   bootrec /fixmbr
   bootrec /fixboot
   bootrec /scanos
   bootrec /rebuildbcd
If the "fixboot" command fails, try forcing it:
bootsect /nt60 sys

3. Recover ACL Defaults for Boot Files​

Sometimes permission changes on C:\Boot or system partition files cause bootloader issues. Run:
Code: 
   icacls C:\Boot /grant "NT AUTHORITY\SYSTEM":F /T
   icacls C:\Windows\System32 /grant "NT AUTHORITY\SYSTEM":F /T
   icacls C:\ /grant Administrators:F /T
Additionally, confirm TrustedInstaller owns critical components:
Code: 
   takeown /F C:\Windows /R
   icacls C:\Windows /setowner "NT SERVICE\TrustedInstaller" /T

4. Force USB Boot Using Boot Menu​

  • Upon startup, press the boot menu key (Esc, F9, F12, etc., depending on your system) immediately.
  • Select your USB recovery drive manually.
  • If the USB still won't boot, ensure it's configured as a UEFI bootable drive (use tools like Rufus to recreate the bootable USB with UEFI support).

5. Reset BIOS/UEFI​

  • Sometimes, BIOS corruption or invalid boot entries cause problems:
    • Remove the CMOS battery for about 10 seconds (or use the "Load Defaults" option in BIOS).
    • If a password is active in BIOS, clear it to ensure unrestricted access.

6. Test USB Boot Media on Another Computer​

  • Ensure the USB drive you’re using is functional by testing it on another system.
  • If the USB drive is corrupt or improperly created, recreate it using Microsoft's Media Creation Tool on another system.

7. Last Resort: Complete Reinstallation​

If all recovery options fail:
  • Recreate the recovery USB.
  • Reboot the system and attempt a clean Windows installation.
  • If access to drives fails during installation, it’s likely the permissions corruption has extended to the partition table, requiring a complete reformat of the drive.
    Important: Back up your drive using third-party tools or external shells if needed before reformatting.
Let me know if you’re still encountering issues!
 
Upvote 0 Downvote
I Can't boot into anything.
 
Upvote 0 Downvote
If you cannot boot into either your system or recovery media, the root issue may be related to corrupted boot configurations, blocked USB initialization, or even BIOS-level disruptions. Below are methods tailored for systems that cannot boot into recovery modes or external drives:

1. BIOS/UEFI Deep Reset​

  • Clear CMOS:
    • Power off the system and disconnect the power cord.
    • Remove the CMOS battery from the motherboard (small coin-sized battery) for about 10-15 seconds.
    • Reinsert the battery and reconnect the power.
  • This will reset the BIOS to factory defaults.
  • Verify Boot Mode in BIOS:
    • Access BIOS/UEFI (press Del, Esc, F2, or a similar key during boot).
    • Ensure the following:
      • USB Support: Enabled.
      • Boot Mode: (Match your system)-EFI/UEFI for modern disks, Legacy/CSM for MBR.
      • Disable Secure Boot temporarily.
    • Save these settings and retry booting from the USB.

2. Recreate USB Recovery Media​

  • If USB media is not recognized, ensure it is properly created as bootable, preferably in UEFI mode:
    • Use Rufus or Microsoft's Media Creation Tool:
      • GPT Partition Scheme for UEFI systems.
      • FAT32 format for compatibility with UEFI boot loaders.
  • Test this USB on another machine to confirm it’s functional.

3. Forced UEFI Recovery​

If USB still doesn't boot:
  • Force Recovery Mode:
    • Turn on your system and force it off during boot by holding the power button.
    • Do this 2-3 times to trigger the Windows Recovery Environment (WinRE).
  • If successful, navigate to Advanced Options > Startup Repair.

4. External Offline Boot Repair​

If no recovery mode is achievable, you may need to:
  • Create a Bootable Linux Live USB such as Ubuntu:
    • Mount the system volume and verify bootloader setups (helps bypass Windows restrictions).
  • Use advanced tools like Hiren’s BootCD PE to:
    • Access Command Prompt.
    • Rebuild bootloader using:
      Code: 
      bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd

5. Testing for Hardware Errors​

  • Rule out issues with:
    • The USB port: Use an alternate port.
    • Storage Device: Rescan for your system disk via diskpart on another bootable device system.
    • Motherboard: Test display cables/secure system.

6. Last Resort: Rebuilding Boot Files Using Alternate Systems​

If you have access to another system:
  • Create a recovery media for Windows or Linux.
  • Test it on the affected system after completing BIOS resets and manual boot file recovery from USB.
These methods focus on recovering functionality step-by-step. If you encounter specific errors during these stages, more tailored troubleshooting may be necessary. Let me know what happens next!
 
Upvote 0 Downvote
after successfully making the cmos reset, it showed a boot option and used the cmd Prompt inside the recovery boot tool (once I freshly recreatd it with rufus) sfc scannow and dsim commands worked, but the actual drive letter still shows the Ghost SID. I have an nvme external tray, and I made sure a second laptop didn't auto scan removing secure boot, automount, and windows securityreal-time protection being off. I opened SetACL Studio on this laptop that is using this nvme as a seperate drive.

based on all the commands we went through, 2796 files consistently failed and so with SetACL, what can I do also after removing the S-1-15-3-65536-1888954469-739942743-... from the main drive letter?
 
Upvote 0 Downvote
Given your usage of SetACL Studio on the NVMe as an external drive with the ghost SID removed, there are still some steps and fixes that you should implement to stabilize the system, repair the leftover ACL corruption, and ensure proper functionality without lingering errors.

Steps to Resolve Files Failing After Ghost SID Removal (2796 Files):​

  1. Verify Ownership with SetACL:
    • Use SetACL Studio to identify files that are still improperly assigned to the ghost SID (S-1-15-3-*).
    • Set ownership of these files back to NT SERVICE\TrustedInstaller (for system-critical files) or Administrators (for non-critical files):
      • Select files affected.
      • Apply ownership using NT SERVICE\TrustedInstaller with full control permissions.
  2. Repair Permissions Cumulatively:
    • For system directories such as C:\Windows\System32, C:\ProgramData, or other critical paths, reapply permissions:
      • Use SetACL to set inheritance to “enabled” for parent directories.
      • Propagate permissions downward:
      • Grant TrustedInstaller Permissions:
        C:\Windows – NT SERVICE\TrustedInstaller: Full Control
      • Restore Defaults for SYSTEM and Administrators:
        SYSTEM and BUILTIN\Administrators: Full Control (inheritance enabled)
  3. Run ICACLS After SetACL for Validation:
    • Open Command Prompt with administrator privileges on your second laptop or the recovery system.
    • Execute:
      icacls F:\ /reset /T /C
      Replace F: with the drive letter assigned to your NVMe. This ensures permissions/reset rules have propagated.
  4. Batch Restore Registry Permissions:
    • Ghost SIDs in the registry may perpetuate ACL issues. After removing SIDs from C:\RegBack or shadow copies, ensure registries follow inheritance:
      • Use command:
        regini path\to\backup.reg
        Or validate with HKEY_LOCAL_MACHINE\SYSTEM.
  5. Rebuild Boot Environment Settings:
    • If the permissions might impact startup services:
      Code: 
      bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcd
  6. Post-Reset: Final ACL Actions for Consistency
    • Re-enable Inheritance:
      Use SetACL Studio to reclaim inheritance rights for critical paths (e.g., C:\Windows, C:\Program Files).
      • Propagate corrections to subdirectories.
    • Confirm no files or directories remain in a “broken” permission chain (e.g., orphan SIDs, missing SYSTEM).
  7. Test System Drive with Recovery Laptop:
    • Recheck drive integrity before mounting it back to the original machine:
      chkdsk F: /F /R
      Replace F: with the drive letter. This ensures no bad sectors are affecting previously inaccessible files.

Troubleshooting Failed Permissions (Persistent Issues):​

  • Use tools such as Sysinternals AccessChk to validate open/restricted access permissions for SYSTEM, Administrators, and TrustedInstaller.
  • Run DISM for a full image repair:
    dism /image:F:\ /cleanup-image /restorehealth
These steps should comprehensively stabilize permissions, remove errors caused by ghost SIDs, and restore functional ACL configurations. Let me know if further iterations of ACL reconstruction are needed!
 
Upvote 0 Downvote
Yes, SetACL Studio allows you to reset permissions across the entire drive, but it's important to understand the implications before proceeding. Here's an overview:

Can You Reset Permissions for the Entire Drive?​

Yes, SetACL Studio supports global permission resets for a volume or directory tree. This is done by applying defined ACL (Access Control List) templates across all files and folders within the selected scope.

Steps to Reset Entire Drive Permissions in SetACL Studio​

  1. Launch SetACL Studio:
    • Open the tool and select your external NVMe drive.
  2. Navigate to the Root Directory:
    • Select the directory corresponding to the root drive (e.g., C:\ or the external drive letter).
  3. Reset Access List:
    • Apply a global ACL reset by enabling the "Reset all Permissions" option. Choose to propagate changes to all subdirectories and files.
      • Enable Inheritance: Ensure the new permissions follow a parent-child hierarchy for consistency.
  4. Assign Ownership:
    • Set ownership of the drive to NT AUTHORITY\SYSTEM or NT SERVICE\TrustedInstaller for system-critical files.
  5. Test Changes:
    • Before resetting the entire drive, try applying changes to smaller directories (e.g., C:\Windows or problematic folders) to confirm the changes fix access issues without causing new ones.

Risks of Full Drive Permission Resets​

  • Breakage Risks:
    • Resetting system directories like C:\Windows or Program Files may prevent essential services from functioning properly if TrustedInstaller ownership is lost.
  • Time-Intensive:
    • Propagating permission changes across an entire drive may take considerable time, depending on the number of files.
  • Possible Corruption:
    • If the operation is interrupted, permissions can end up in an inconsistent state, causing additional errors.

Safer Alternatives to Full Reset​

Instead of resetting the entire drive:
  1. Repair High-Level Directories:
    Focus on critical system folders, such as:
    • C:\Windows
    • C:\Program Files
    • C:\ProgramData
      Use these targeted fixes for permission reconstruction and avoid overwriting user directories like Documents or Downloads.
  2. Use ICACLS Commands After SetACL Studio:
    Post-reset, run the following in an elevated Command Prompt to validate changes and fix inheritance:
    icacls C:\ /reset /T /C /Q
  3. Combine with SFC and DISM:
    After resetting permissions or clearing ghost SIDs, follow up with:
    Code: 
    sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

Key Notes​

  • Preferred Use Cases:
    • If majority of directory permissions are corrupted or SIDs like S-1-15-... persist.
  • Not Recommended:
    • If only specific subdirectories are problematic. Instead, apply changes to the affected folders only.
Carefully evaluate whether a global reset is necessary for your use case, and always create a backup of critical data if possible before altering permissions . Let me know if you’d like guidance on replicating these steps!
 
Upvote 0 Downvote
You must log in or register to reply here.

Similar threads

B
Windows 7 ACLs, partitions and users profiles
Replies
1
Views
1K
ChatGPT