`Remove-WindowsUpdate` crash issue

[MizardX]

Since Issues has been disabled, and the source code is not available, and there is no other way to contact you, I will add this here.

The Remove-WindowsUpdate command crashes with error "Object reference not set to an instance of an object." if you use -UpdateID parameter.

I believe this is because it tries to update the KBArticleID property (to remove the "KB" prefix), even though it is null.

It is impossible to give KBArticleID a value when using the -UpdateID parameter, since it is on a different parameter set.

Decompiled sources:

namespace PSWindowsUpdate
{
  [Cmdlet("Remove", "WindowsUpdate", ConfirmImpact = ConfirmImpact.High, SupportsShouldProcess = true)]
  public class RemoveWindowsUpdate : PSCmdlet
  {
    ...
    private void CoreProcessing()
    {
      string invocationName = this.MyInvocation.InvocationName;
      string str1 = this.KBArticleID.Replace("KB", ""); // <-- here
      foreach (string str2 in this.ComputerName)
      {
      ...

[sarog]

It's been over a month and the issue hasn't been resolved. I went ahead and forked the project and applied a (possible) fix. I basically moved the variable further down under WUSAMode where I suspect it belongs.

While I don't expect you to build or use my repo, I do encourage you to use dnSpy to modify the method and then recompile the original DLL. Chances are this will break the code sign, so it's probably best to re-sign the file with your own trusted certs.

[God-damnit-all]

It's been over a month and the issue hasn't been resolved. I went ahead and forked the project and applied a (possible) fix. I basically moved the variable further down under WUSAMode where I suspect it belongs.

While I don't expect you to build or use my repo, I do encourage you to use dnSpy to modify the method and then recompile the original DLL. Chances are this will break the code sign, so it's probably best to re-sign the file with your own trusted certs.

@mgajda83 Why exactly is the source code for the binary not being made available anyway?

[God-damnit-all]

@sarog I was able to get your fork to compile, but the readme mentions that you're still undergoing refactoring and it's still not ready for production environment use.

I attempted to recompile the original dll using dnSpyEx instead, simply moving the line into the WUSAMode section as instructed, but it wanted a WUApiLib reference and I couldn't figure out how to supply it to the program.

[sarog]

@sarog I was able to get your fork to compile, but the readme mentions that you're still undergoing refactoring and it's still not ready for production environment use.

You can use it in production if you are confident with the code. Apart from a few artifacts that I have yet to review & clean up, it was an easy decompile and will most likely work fine.

I attempted to recompile the original dll using dnSpyEx instead, simply moving the line into the WUSAMode section as instructed, but it wanted a WUApiLib reference and I couldn't figure out how to supply it to the program.

wuapi.dll is found under C:\Windows\System32\.

[God-damnit-all]

You can use it in production if you are confident with the code. Apart from a few artifacts that I have yet to review & clean up, it was an easy decompile and will most likely work fine.

I'm more concerned with the maintainer's confidence in the code.

wuapi.dll is found under C:\Windows\System32\.

I'd figured as much, but it doesn't seem to make a difference:

[sarog]

I'd figured as much, but it doesn't seem to make a difference:

Do you have the Windows 10 SDK installed?

[God-damnit-all]

I'd figured as much, but it doesn't seem to make a difference:

Do you have the Windows 10 SDK installed?

Sure do.

I wouldn't have been able to compile your fork without it.

Also, I tried launching dnSpy from VsDevCmd.bat to see if that made a difference, but, unfortunately, it did not.