PolFileEditor.dll is locked.

[brwilkinson]

The process cannot access the file 'C:\\Program Files\\WindowsPowerShell\\Modules\\PolicyFileEditor\\PolicyFileEditor\\PolFileEditor.dll' because it is being used by another process.

[brwilkinson]

So I am still using this module... figured I would take another look at the issue.

handle 'C:\Program Files\WindowsPowerShell\Modules\PolicyFileEditor\PolicyFileEditor\PolFileEditor.dll'

WmiPrvSE.exe       pid: 4640   type: File           B34: C:\Program Files\WindowsPowerShell\Modules\PolicyFileEditor\PolicyFileEditor\PolFileEditor.dll

@dlwyatt did you have any ideas on this ?

I see load file and save file. Does this need an unload file or dispose or something ? Perhaps could put that in a finally block ?

[dlwyatt]

Those functions are what gets exported by the dll, but have nothing to do with locking the dll itself. I'm not sure why this would be happening.

WmiPrvSE.exe is the process that runs the DSC Local Configuration Manager, though. Are you using this in a configuration on your system?

[brwilkinson]

@dlwyatt

I use it to deploy out some default settings on Jump servers.

It's my last resort method to setting some specific user settings, that are difficult to handle via other methods.

Yeah it's a random lock, however I have seen this happen with my customers, it gets locked about 1 in 25 deployments. That is enough for them to comment out using this.

I wasn't really sure if there would be a way to dispose of any in memory objects in a finally block that may be locking the dll in memory ?

where does "PolFileEditor.dll" come from ?

[dlwyatt]

It's something I wrote when I first started learning PowerShell. I had a class written in VBScript to do these same tasks, and wound up porting that to C# first (because I thought that's how you did "classes" for use in PowerShell scripts... lol)

Anyhow, there's no way to unload a .NET dll other than exiting the process, and this includes things you've added via Add-Type in PowerShell. However, what that doesn't explain is why it's locking the dll for use from other programs. Normally you can fire up as many PowerShell sessions as you want and call Add-Type (or Import-Module, whatever) on the same DLL from each of them without problems.

[brwilkinson]

Yeah that is why I was thinking it must be a reference to the dll that we maybe able to dispose of or something...

I feel like if perhaps the policy file was loaded, however then it never made it to the SAVE... that would be the most likely reason. So I was thinking if there was an UNLOAD method i.e. abort writing the policy in a Finally block, that may do it.

[dlwyatt]

If the error message you were describing was about the registry.pol file, that might be an accurate description. But it's complaining about the PolFileEditor.dll file being locked, which is just the code in this module. Shouldn't matter whether it has any files open or not (unless two PowerShell sessions were trying to change the same policy file a the same time, but then the error would be the path to that .pol file, not to the .dll)

[brwilkinson]

right... well something still has a handle on the file 🙂 hmmm 🤔

So it must be something in either the GET/SET/TEST . . . probably test, since I am sure a setting has already been applied. Perhaps just from the helper functions, since they get loaded all the time.

Anyway I just wanted to check with you... I'll see if i can find anything in the logs etc that maybe helpful.

[brwilkinson]

okay yeah I think i see the issue now.

It's actually the DSC extension that is causing the Error. Not the execution of the policy itself.

i.e. DSC extension in i the process of Staging the Modules, when it fails. i.e. it cannot delete the old 'PolicyFileEditor' in order to copy in the new set of Modules for the latest deployment.

[dlwyatt]

That makes sense. However, that dll file has never changed since long before I wrote the PowerShell wrapper around it, and probably never will change again because I can't find the C# source anymore now that Microsoft retired the TechNet Gallery 😭 . So your staging scripts can safely skip copying that file if it's already present.

[brwilkinson]

[brwilkinson]

Essentially this could occur if DSC is not in the desired state. i.e. it has a Pending config.

Then you kick out a re-deploy. . . good to know. Thanks.

So the workaround is: Stop-DSCConfiguration -force ... prior to a redeploy and that should avoid the conflict.

[brwilkinson]

hey you might be in luck on the Gallery stuff.... try this...

head over here: https://social.technet.microsoft.com/profile/David%20Wyatt

Sign in, then go to privacy... there is a download option.

I actually created this Github project to re-stage your own Gallery content and put a search bar on top of it.

This is my script center content staged: https://brwilkinson.github.io/msdn-scriptcenter-repo/

This is the repo, if you clone it there are hopefully easy instructions to re-stage you content that you downloaded from the Privacy page. Let me know if you get stuck on anything and need a hand.

This is the repo: https://github.com/brwilkinson/msdn-scriptcenter-repo/tree/main it's just a Jekyl/Github pages repo.

[dlwyatt]

Awesome, thanks for that! :) Wow, it's even got all my old VBScript stuff. 😱

[brwilkinson]

SWEEEET :)

I noticed about 70% of my stuff was available in the download, not all for some unknown reason.

Some of these may show up again in a GitHub archive page, however there is no current timeline.

[brwilkinson]

Hopefully that wasn't too much of a rabbit hole 🤔

[brwilkinson]

Feel free to close out this issue.... I might see If I can get an option on the VM DSC extension to only update modules if it's a new version of the Module.