{"id":2711,"date":"2013-10-19T00:01:00","date_gmt":"2013-10-19T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2013\/10\/19\/weekend-scripter-use-powershell-and-pinvoke-to-remove-stubborn-files\/"},"modified":"2013-10-19T00:01:00","modified_gmt":"2013-10-19T00:01:00","slug":"weekend-scripter-use-powershell-and-pinvoke-to-remove-stubborn-files","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/weekend-scripter-use-powershell-and-pinvoke-to-remove-stubborn-files\/","title":{"rendered":"Weekend Scripter: Use PowerShell and Pinvoke to Remove Stubborn Files"},"content":{"rendered":"

Summary<\/strong>: Windows PowerShell MVP, Boe Prox, talks about using Windows PowerShell and Pinvoke to delete locked files.<\/p>\n

Microsoft Scripting Guy, Ed Wilson, is here. Today we have a guest blog post by newly crowned Windows PowerShell MVP, Boe Prox. Long-time readers of the Hey, Scripting Guy! Blog are familiar with Boe’s work, but this is his first guest blog post as an MVP. WooHoo!<\/p>\n

Boe Prox is a Microsoft MVP in Windows PowerShell and a senior Windows system administrator. He has worked in the IT field since 2003, and he supports a variety of different platforms. He is also an Honorary Scripting Guy and has submitted a number of posts as a guest blogger, which discuss a variety of topics. He is a contributing author in PowerShell Deep Dives<\/a> with chapters about WSUS and TCP communication. He is a moderator on the Hey, Scripting Guy! forum<\/a>, and he has been a judge for the Scripting Games since 2010. He recently presented talks on the topic of WSUS and Windows PowerShell at the Mississippi PowerShell User Group<\/a>.<\/p>\n

To read more of his posts, see these Hey, Scripting Guy! Blog posts by Boe Prox<\/a>.
<\/strong>Boe’s blog: Learn Powershell | Achieve More
<\/a>Codeplex projects: PoshWSUS<\/a>, PoshPAIG<\/a>, PoshChat<\/a>, and PoshEventUI<\/a><\/p>\n

Take it away, Boe…<\/p>\n

Note<\/strong>  The complete script for this blog post<\/a> is available via the Scripting Guys Script Repository.<\/p>\n

We have all been there. A file that we need to delete is locked by some process that we are unable to kill for one reason or another, and we have to reboot the system in hopes that by the time we get signed in to the system, it will not have a lock on the file. Wouldn’t it be great if we can just mark the file for deletion after a reboot and not worry about it being around by the time we sign in? If you answered, “Yes!” to this question, stick around because I will show you how to accomplish this task by using Windows PowerShell and hooking into the Win32 API using Pinvoke.<\/p>\n

One of the many beauties of Windows PowerShell is its ability to use inline code (C# for example) that can be compiled by using Add-Type<\/strong> and then called to perform an action. By doing so, you can leverage some pretty powerful low-level functions to do things that you just cannot do natively via Windows PowerShell.<\/p>\n

The first thing that needs to be done is determine what we can use to make this work. Looking at Pinvoke.net<\/a> (a great website for finding out what is available to use with Pinvoke), I find the MoveFileEx<\/strong> function and the C# signature that we can put to work in Windows PowerShell.<\/p>\n

\"Image<\/a><\/p>\n

Looking at the MoveFileEx<\/strong> function, I see three parameters (lpExistingFileName, lpNewFileName<\/strong>, and dwFlags<\/strong>) that are required for the function to operate correctly. The first two parameters are pretty simple to understand: we need the source file that will be deleted and then we need a destination file. If this sounds like it an issue, trust me, it isn’t. All I need to do is specify $Null<\/strong> in its place, and the file will be marked for deletion instead. Of course, all of this rests in the hands of the dwFlags<\/strong> parameter that is still left to deal with.<\/p>\n

Looking at the same page, I can see a link to MoveFileFlags (Enum)<\/a> where I can get info about the available flags. Judging from the information, I only need to supply 0x4 as the flag to mark the file for deletion after a reboot. Or I can more easily create the Enum<\/strong> and reference the proper value (MOVEFILE_DELAY_UNTIL_REBOOT).<\/p>\n

\"Image<\/a><\/p>\n

Although this is fine, I would prefer to know what each one means. Fortunately, I can also check out the Windows Dev Center page about this: MoveFileEx function<\/a>.<\/p>\n

From here, I find the flag that I am most curious about, MOVEFILE_DELAY_UNTIL_REBOOT<\/strong>.<\/p>\n\n\n\n
\n

MOVEFILE_DELAY_UNTIL_REBOOT<\/strong><\/p>\n

4 (0x4)<\/p>\n<\/td>\n

\n

The system does not move the file until the operating system is restarted. The system moves the file immediately after AUTOCHK is executed, but before creating any paging files. Consequently, this parameter enables the function to delete paging files from previous startups.<\/p>\n

This value can be used only if the process is in the context of a user who belongs to the administrators group or the LocalSystem account.<\/p>\n

This value cannot be used with MOVEFILE_COPY_ALLOWED<\/strong>.<\/p>\n

Windows Server 2003 and Windows XP:  <\/strong>For information about special situations where this functionality can fail, and a suggested workaround solution, see Files are not exchanged when Windows Server 2003 restarts if you use the MoveFileEx function to schedule a replacement for some files<\/a> in the Help and Support Knowledge Base.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 The key takeaway here is that only an Administrator can really utilize this flag to mark a file for deletion. In case you were wondering how I know that this flag is used in conjunction with the second parameter of the MoveFileEx<\/strong>, check out the description for the lpNewFileName<\/strong> parameter:<\/p>\n

\"Image<\/a><\/p>\n

By using this information, I can create a Here-String<\/strong> and supply it to Add-Type<\/strong> to create a compiled type that can be used in our example to mark a file for deletion.<\/p>\n

Add-Type @”<\/p>\n

    using System;<\/p>\n

    using System.Text;<\/p>\n

    using System.Runtime.InteropServices;<\/p>\n

       <\/p>\n

    public class Posh<\/p>\n

    {<\/p>\n

        public enum MoveFileFlags<\/p>\n

        {<\/p>\n

            MOVEFILE_REPLACE_EXISTING           = 0x00000001,<\/p>\n

            MOVEFILE_COPY_ALLOWED               = 0x00000002,<\/p>\n

            MOVEFILE_DELAY_UNTIL_REBOOT         = 0x00000004,<\/p>\n

            MOVEFILE_WRITE_THROUGH              = 0x00000008,<\/p>\n

            MOVEFILE_CREATE_HARDLINK            = 0x00000010,<\/p>\n

            MOVEFILE_FAIL_IF_NOT_TRACKABLE      = 0x00000020<\/p>\n

        }<\/p>\n

 <\/p>\n

        [DllImport(“kernel32.dll”, SetLastError = true, CharSet = CharSet.Unicode)]<\/p>\n

        static extern bool MoveFileEx(string lpExistingFileName, string lpNewFileName, MoveFileFlags dwFlags);<\/p>\n

        public static bool MarkFileDelete (string sourcefile)<\/p>\n

        {<\/p>\n

            bool brc = false;<\/p>\n

            brc = MoveFileEx(sourcefile, null, MoveFileFlags.MOVEFILE_DELAY_UNTIL_REBOOT);         <\/p>\n

            return brc;<\/p>\n

        }<\/p>\n

    }<\/p>\n

“@<\/p>\n

I’ll caveat this by saying that I am not a C# developer, but I can work my way around the code to make this work the way I want it to. My original intention was to simply reference the MoveFileEx<\/strong> method with my custom type, but supplying $Null<\/strong> into the NewFileName<\/strong> parameter would not work properly. In fact, it assumes that $Null<\/strong> is the actual file name, and it would throw an error when it couldn’t locate it. So with that, I had to dip my toes into the C# waters to make some adjustments to get this to work properly.<\/p>\n

We can verify that this actually worked by calling the new type with the static method:<\/p>\n

[Posh]::MoveFileEx<\/p>\n

\"Image<\/a><\/p>\n

Perfect! Now I just need to pick out a file that I want to test this against.<\/p>\n

Warning<\/strong>  This has the potential to greatly cause havoc to your system if you pick the wrong file or a system file to mark for deletion! Use at your own risk!<\/p>\n

Well look at this, a test.txt file just waiting to be deleted:<\/p>\n

\"Image<\/a><\/p>\n

When you are working with this method and supplying the file name, it is important that you provide the full name of the file. Adding only the file name will have unintended results.<\/p>\n

[Posh]::MarkFileDelete(“C:\\users\\Administrator\\Desktop\\TEST.txt”)<\/p>\n

\"Image<\/a><\/p>\n

This will return a Boolean value (True = file marked for deletion; False = something happened and needs to be looked at). To really see what the issue is other than a False value, we will have to force the error out by calling System.WindowsComponent.Win32Exception<\/strong>:<\/p>\n

Throw (New-Object System.ComponentModel.Win32Exception)<\/p>\n

\"Image<\/a><\/p>\n

In this case, the error is nothing more than a confirmation that the command worked. But if a False value was returned, this error would let you know why it was returned.<\/p>\n

How can we verify that this will actually happen? The registry will provide the answer to this question. By navigating to HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\SessionManager<\/strong> and looking for the PendingFileRenameOperations<\/strong> property in the registry, you should see the file name listed and nothing on the next line. (You may have multiple operations for deletions or moves in this property, which will have the original file and the new location listed directly after the original file.)<\/p>\n

(Get-ItemProperty -Path ‘HKLM:\\SYSTEM\\CurrentControlSet\\Control\\Session Manager’ -Name ‘PendingFileRenameOperations’).PendingFileRenameOperations<\/p>\n

\"Image<\/a><\/p>\n

\\??\\C:\\users\\Administrator\\desktop\\test.txt<\/strong> is what we are looking for. That space after the file is there for a reason.  What this means is that as soon as we reboot the system, this file will be gone the next time we sign in. Now queue the reboot:<\/p>\n

Restart-Computer -Force<\/p>\n

Now we are back and signed in to the system. Let’s check to see if the file is still around.<\/p>\n

\"Image<\/a><\/p>\n

Nope, it is long gone. And we can also check the registry to see if we have any pending file operations:<\/p>\n

(Get-ItemProperty -Path ‘HKLM:\\SYSTEM\\CurrentControlSet\\Control\\Session Manager’ -Name ‘PendingFileRenameOperations’).PendingFileRenameOperations<\/p>\n

\"Image<\/a><\/p>\n

Well, it is a good sign that there is nothing in the registry. So with that, you have seen how to use the MoveFileEx<\/strong> method with Pinvoke to mark a file for deletion after a reboot. You can also use this on directories, but the directory must have no child items (files or folders) in it for this to work.<\/p>\n

Of course, I couldn’t stop at this. I also made a function (Register-FileToDelete<\/strong>) that makes this a much easier process and allows for verbose logging, -WhatIf<\/strong> parameter (because if you are doing something that has potential to make a change, you better have this), and handles input from the pipeline. You can download this function from the Script Center Repository: Register-FileToDelete<\/a>.<\/p>\n

Here is an example of what would happen if I simply wanted to hit all .txt files, and I use the –WhatIf<\/strong> switch to avoid accidently deleting the files:<\/p>\n

Get-ChildItem -File -Filter *.txt | Register-FileToDelete -WhatIf<\/p>\n

\"Image<\/a><\/p>\n

In this instance, only two files would have been deleted after the reboot. So now let’s mark the test.txt file for deletion:<\/p>\n

Get-ChildItem -File -Filter test.txt | Register-FileToDelete -Verbose<\/p>\n

\"Image<\/a><\/p>\n

And there you have it! The next time this system reboots, it will delete the file.<\/p>\n

That is all for working with Pinvoke and utilizing the MoveFileEx<\/strong> function to make it easier to remove a file that may be locked by a process after a reboot. Hope you enjoyed it!<\/p>\n

~Boe<\/p>\n

Thank you, Boe, for an awesome post, and one that will be immediately useful to many readers.<\/p>\n

I invite you to follow me on Twitter<\/a> and Facebook<\/a>. If you have any questions, send email to me at scripter@microsoft.com<\/a>, or post your questions on the Official Scripting Guys Forum<\/a>. See you tomorrow. Until then, peace.<\/p>\n

Ed Wilson, Microsoft Scripting Guy<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

Summary: Windows PowerShell MVP, Boe Prox, talks about using Windows PowerShell and Pinvoke to delete locked files. Microsoft Scripting Guy, Ed Wilson, is here. Today we have a guest blog post by newly crowned Windows PowerShell MVP, Boe Prox. Long-time readers of the Hey, Scripting Guy! Blog are familiar with Boe’s work, but this is his […]<\/p>\n","protected":false},"author":596,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[162,40,56,3,4,12,61,45],"class_list":["post-2711","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-boe-prox","tag-filesystemobject","tag-guest-blogger","tag-scripting-guy","tag-scripting-techniques","tag-storage","tag-weekend-scripter","tag-windows-powershell"],"acf":[],"blog_post_summary":"

Summary: Windows PowerShell MVP, Boe Prox, talks about using Windows PowerShell and Pinvoke to delete locked files. Microsoft Scripting Guy, Ed Wilson, is here. Today we have a guest blog post by newly crowned Windows PowerShell MVP, Boe Prox. Long-time readers of the Hey, Scripting Guy! Blog are familiar with Boe’s work, but this is his […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/2711","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/596"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=2711"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/2711\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=2711"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=2711"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=2711"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}