PS script error

Question

PS script error

Hram Admin 120

Hello!

I have a few scripts that delete old backups from some folders. There's actually one string that deletes the oldest folder:

Remove-Item -Path [Folder Name] -Recurse -Force

...and it works perfect for all folders except the one: while deleting this folder the script terminates with the error 0xC00000FC or - if run in ISE - the ISE itself exits and gets restarted.

This folder is different from any other only in containing user profiles, but the script is run with the #Requiers Administrator option so it must have the right to delete them.

Either script or ISE doesn't even delete anything - the folder size never changes, it seems the script just hangs for ~5-7 minutes and then crashes with 0xC00000FC.

What can be the cause of this?

Regards,
Michael

7 answers

Your answer

Answer 1

Rich Matheisen 47,786

It might be a damaged profile, or a profile with a very long name, or a profile with security that's unexpected. Or, it may be a damaged disk (perhaps a bad sector?).

Sometimes just running with administrative privileges isn't sufficient (see unexpected security). Try running your script with backup and restore privileges.

FYI, the Remove-Item will also remove (or try to) any sub-directories it encounters. Is that your intention?

If you encounter a profile that's difficult to remove, you might want to try using delprof2 (https://helgeklein.com/free-tools/delprof2-user-profile-deletion-tool/).

I don't think this is a PowerShell problem, though.

Hram Admin 120 Reputation points

2025-04-16T09:59:25.4466667+00:00

Hi Rich Matheisen,

Thank you for the reply!

"the Remove-Item will also remove (or try to) any sub-directories it encounters. Is that your intention?" - yes, it's exactly what I need.

Didn't get this: "Sometimes just running with administrative privileges isn't sufficient (see unexpected security). Try running your script with backup and restore privileges." - doesn't a member of administrator group has the backup/restore priveleges?

By the way, the script crashes even after I have reset permissions on the folder :(

Regards,
Michael
Rich Matheisen 47,786 Reputation points

2025-04-16T15:53:45.67+00:00

Yes, "Run as administrator" should give you the necessary permissions.

What version of PowerShell are you using? You say you use the ISE so I'm assuming you're running Windows PowerShell (powershell.exe) and not "Powershell" (pwsh.exe). If so, is it the latest version of Windows PowerShell 5.1?

Getting a list of all the files you want to remove, and then removing them one at a time (recording the name of each one before attempting to remove it) might help you locate the problem.

Have you tried delprof2?
Hram Admin 120 Reputation points

2025-04-17T13:49:35.53+00:00

Yes, it's powershell.exe, version 5.1.20348.2849 .

Getting a list of all the files you want to remove, and then removing them one at a time (recording the name of each one before attempting to remove it) - agree!

Have you tried delprof2? - no, I have no issues deleting the folder manually so here's the main question: if I can easily delete ....say FOLDER1 as local admin manually then what prevents PS from doing exactly the same in the console ?

Answer 2

Hram Admin 120

"I don't think this is a PowerShell problem, though." - seems it is obviously PS bug:

Test 1: PowerShell

Remove-Item -Path D:\Backup\PROFILES\Personal\User1\Desktop\ -Recurse -Force

Result: Always Hangs

Test 2: CMD

rd /S /Q D:\Backup\PROFILES\Personal\User1\Desktop\

Result: Deleted

Answer 3

MotoX80 35,726

I don't think that Remove-Item has an option to deal with symbolic links. Get-ChildItem has the -FollowSymlink switch to override its default. I suspect that you are running into the recursive "application data" feature.

https://superuser.com/questions/1559693/robocopy-loops-nests-application-data-29-times-when-copying-application-data

Remove-Item would need the equivalent of robocopy's /XJ or /XJD switches.

From a command prompt you can run this to see what links are defined.

dir D:\Backup\PROFILES\Personal\User1\Desktop\ /a /s | findstr "<JUNCTION>"

I have not tested this, but I would think that you should be able to use Get-Childitem as a workaround.

Get-ChildItem Path D:\Backup\PROFILES\Personal\User1\Desktop\ -Recurse | Remove-Item -Force

Hram Admin 120 Reputation points

2025-04-23T13:58:04.4233333+00:00

MotoX80, thank you for the interesing information - I'll check it!

""I don't think that Remove-Item has an option to deal with symbolic links." - does it have to? What for??? I did some testing and didn't get anyting, for example:

Remove-Item -Path D:\Backup\PROFILES\Personal\User1\Desktop\ -Recurse -Force - PS hangs or restarts

Remove-Item -Path D:\Backup\PROFILES\Personal\User5\Desktop\ -Recurse -Force - deleted OK

Remove-Item -Path D:\Backup\PROFILES\Personal\User8\ -Recurse -Force - deleted OK

All user profiles seems to be ~the same...

By the way, it seems strange to me that the ancient rd /S /Q deletes everything without any issue while the modern Remove-Item can be missing some capabilities...
Rich Matheisen 47,786 Reputation points

2025-04-23T16:02:27.67+00:00

There are many significant differences between stand-alone executables compiled and statically linked with libraries, and Microsofts' "managed code" executables that use .NET (and sometimes break when new DLLs are delivered).

I think the asynchronous problem went away with Windows 10 update 20H2. There may still be conditions that cause problems, though.

In the past, the managed code performed the deletion of a directory asynchronously. But that can cause problems if, say, a directory was deleted and then referenced before the deletion was complete (which may be happening when you use "-Recurse". Even the "rd" command would occasionally fail when using the "/S" option (just not as often).

An interesting analysis of the original problem, along with a PowerShell function that purports to avoid much of the problem is here: https://stackoverflow.com/questions/53553729/cannot-remove-item-the-directory-is-not-empty/53561052#53561052
MotoX80 35,726 Reputation points

2025-04-23T18:39:41.2+00:00
So the question is: when a program is accessing the file system and comes across a symbolic link, does it (A) treat the link as an object itself to be processed or does it (B) follow the link and process the files/directories in the linked folder.

Get-help get-childitem shows this.

-FollowSymlink <System.Management.Automation.SwitchParameter> > [!NOTE] > This parameter is only available in the > FileSystem (../Microsoft.PowerShell.Core/About/about_FileSystem_Provider.md)provider. By default, the `Get-ChildItem` cmdlet displays symbolic links to directories found during recursion, but doesn't recurse into them. Use the FollowSymlink parameter to search the directories that target those symbolic links. The FollowSymlink is a dynamic parameter and is supported only in the FileSystem provider. This parameter was introduced in PowerShell 6.0.

The developers of get-childitem chose option (A), but in PS 6.0 added that switch to allow it to use option (B).

Robocopy help shows this.

/XJ :: eXclude symbolic links (for both files and directories) and Junction points. /XJD :: eXclude symbolic links for Directories and Junction points. /XJF :: eXclude symbolic links for Files.

The developers of robocopy chose option (B), but included switches to allow it to use option (A) if that's what a user needed.

I have no idea why the MS developers came up with "documents and settings" and "application data", and the various links, but the root problem here is that Application Data ends up pointing back to itself.

So programs like robocopy that default to option (B), get into an infinite loop following the links. If remove-item hangs, then I would expect that to be your primary suspect.

Since you are referencing user's profile folders, I would think it likely that you are running into the Application Data recursion problem. That would be the most logical assumption. You would need to look for junctions and see if they are recursive. I would not expect the Desktop folder to exhibit that problem, but we have no way of knowing what your users have in their folders,

Add the verbose switch to the remove-item and see what it shows.

PS C:\temp> remove-item .\deltest\ -recurse -verbose VERBOSE: Performing the operation "Remove Directory" on target "C:\temp\deltest\". VERBOSE: Performing the operation "Remove File" on target "C:\temp\deltest\x.txt". VERBOSE: Performing the operation "Remove File" on target "C:\temp\deltest\z.txt".

You should also be able to see that with robocopy. Use the "/l" switch to just list the files that it finds. (No files copied.) See if can list off the files/folders or if just keeps running.

robocopy D:\Backup\PROFILES\Personal\User1\Desktop\ c:\temp /e /l

Answer 4

MotoX80, thank you so much for this - https://superuser.com/questions/1559693/robocopy-loops-nests-application-data-29-times-when-copying-application-data - I didn't know it!

Regarding the problem with Application Data: I'm trying to delete the folders that do NOT contain Application Data (they are the folders created by another backup which does not copy Application Data) so I think it's not the case:

dir D:\16042025\Personal\User1\Desktop\ /a /s | findstr "<JUNCTION>"

dir D:\16042025\Personal\User1\ /a /s | findstr "<JUNCTION>"

both returns nothing.

Here are my tests:

-robocopy does list each object as excpected...

...but Remove-Item seems not :(

Answer 5

Get-ChildItem Path $fdel.Name -Recurse | Remove-Item -Force did not hang, did not delete anything and displayed (I mean set Error[0]) PathTooLongException error.

However I'm not sure if it is the root problem that makes Remove-Item crash /hang or not because (at least I think so) other folders that are being deleted by the script may also contain long names, but nevertheless they are deleted successfully...

In any case it's rather strange to have problems with deleting files with long paths and do not have the same problems when copying that files to backup directory - theoreticaly the error should have arisen while copying first, not while deleting.

Share via

PS script error

7 answers

Your answer