I have already reported this to Pulseway Support and am meeting with them ovcer Zoom today to try and resolve. I am trying to gain more information and see if the community is also having issues. We have been deploying the Pulseway windows_agent_x64.msi over GPO as I image them and move them to an OU "Open and Ready" designated for deployment of the application.

In late October we imaged and deployed many Windows 11 laptops without issues. None of those deployed laptops seem to having this issue... working great. This month I have swapped out some older Windows 11 laptops and reimaged them, and installed the Pulseway agent over GPO as usual... Install goes fine but then the agent wont update and Remote Control is missing... the Update log does not get updated and the machine enver receives updates... it's broken. Very Broken.

I have tried other methods and get an error:
Pulseway: "This advertised application will not be installed because it might be unsafe. Contact your administrator to change the installation interface option of the package to basic."

I have tried:
Recreating the GPO Policy.
Updated Software Restirctions Policy to include the msi path.
Updated the Trusted Root Certificates. (roots.sst)
Manually installed from local drive
Disabled UAC on the Laptop (for testing)
Tried repair installation after install
Removed the latest Windows 11 Updates (The ones I can remove)
NO Antivirus installed / Firewall disabled (for testing)
Verified the .msi cert is valid...

SignerCertificate                         Status                                 Path
-----------------                         ------                                 ----
C32461866177F1AA99D7592E269EBDDC083AA0FD  Valid        windows_agent_x64.msi

>>> NONE of this fixes it.

This has been working flawlessly for over a year... Not sure what broke it.
No Major changes here... Network has been flawless... Windows 11 amazing.

This a Pulseway problem?
I don't like the blame games... I am about function and working to fix / progress.
I see another posts with .Net issues and Agent failure and wonder if this is related.

Any help or Suggestions are Appreciated!! Crazy!
> I may install Windows 10 on a system and see if the PW Agent is still broken or if I can getr more infomration. (Windows 10 no longer supported of coarse)

Edited 6 hours ago6 hr by BobBrown
Because

Just tested using Windows 10 and have the same issue. No Remote Control and will not update using the agent. (sad)
Next I am trying a Windows 11 Stand Alone... off the domain to make 100% sure this is not GPO driven issues.

This is really starting to look like a Pulseway issue... they must change things on the back end that effects the agents. (assumption)
Only thing that has changed here is a few non relative Windows updates last weekend to the servers.

The fact that it is not affecting already installed agents is a clue...

I think I figured it out.
The download that Pulseway provides us is corrupt? Verison mismatch.
Installs as 9.5.1 and then shortly after downgrades the GUI to 9.24

OOOPS.
They have no idea how much time this has cost me... HOURS of BS. Not happy Pulseway!

Edited 1 hour ago1 hr by BobBrown

Just got of a call with Support and we figured out what happened. Answer: Blotched agent upgrade for our instance.
They deployed the 9.24 version a few weeks back and we got the corrupt 1/2 updated hybrid 9.5.1.9.24 version.

In reality the GUI said 9.24 and the dll's/program Files were 9.5.1 (post above)
>> I am assuming this is a "one off"... but if anyone else has this issue... check the versions of the GUI vs Installed Programs.

Here are all the juicy details and how I figured it out... HOPEFULLY THIS HELPS SOMEONE?!?!!?
> Upload the Trace log file to AI/Chat GPT and have it examine the logs....

ME: "Examine this log file and tell me why 3PP failed."

3PP didn’t fail because of Windows Updates — it failed because Pulseway couldn’t install its Software Management Client (SMClient) module, and that install is crashing with a MissingMethodException.

What the log shows (the actual failure)

Right after OS patching finishes, Pulseway starts “3rd party patching” and tries to download/install SMClient:

• “Starting 3rd party patching…”

• It downloads smclient.zip successfully.

• Then it throws:

System.MissingMethodException: Method not found: 'Void MM.Framework.Utils.IOOperations.Write(System.String, System.String, Boolean)'.

And immediately after:

System.Exception: Failed to install the SMClient.

Pulseway repeats this multiple times (11:39, 11:47, 11:59) — same error, same outcome, so 3PP never even gets to patch scanning/installing third-party apps.

Why that exception matters

A MissingMethodException almost always means version mismatch: the SMClient/module downloader is calling a method signature that isn’t present in the MM.Framework DLL actually installed on this machine (or it’s the wrong version / corrupted / partially updated). In other words: Pulseway components are out of sync.

You can see the same missing method error earlier during service startup too, which supports “agent install mismatch/corruption” vs a one-off patch module issue.

What to do next (practical fix path)

1. Confirm Pulseway agent version/build and patch module versions on the endpoint match what your server expects (you’re running “Pulseway Service ver. 9.24 build 107” here).

2. Repair/upgrade the Pulseway agent (in-place reinstall usually fixes the mismatched DLLs).

3. If reinstall isn’t possible immediately: check C:\Program Files\Pulseway\Patch\ for partially extracted servermodule-15-12 content and stale DLLs, but honestly this is usually solved fastest by agent reinstall/repair so all assemblies line up.

ME: Appears the versions do not match. Installed Programs says 9.5.1 and the GUI Says 9.24. What cpould cause this? Is this something Pulseway messed up during an upgrade a few weeks ago? They deployed the 9.24 to all US customers and appears I got lucky with a corrupt upgrade?

Yep — what you’re seeing fits perfectly with the failure in the log, and it screams “mixed/partial upgrade.”

1) The key fact: 3PP is failing because the agent’s binaries don’t agree with each other

In the log the Pulseway service starts as 9.24 build 107

, but immediately throws:

System.MissingMethodException: Method not found: 'Void MM.Framework.Utils.IOOperations.Write(System.String, System.String, Boolean)'.

That exact same missing method error happens again when it tries to install the SMClient module (the thing 3PP needs), and then 3PP aborts:

• “Starting 3rd party patching…”

• SMClient download succeeds

• SMClient install fails with the same MissingMethodException

• “Failed to install the SMClient.”

So: 3PP failed because the module installer is calling a method that doesn’t exist in the version of MM.Framework actually loaded on the box. That’s classic “DLL version mismatch.”

2) Why Programs & Features says 9.5.1 while the GUI says 9.24

This is super common with Windows installers:

• Programs & Features shows the MSI “ProductVersion” (what the installer package claims).

• The Pulseway Manager GUI shows the app/service build (what the executable reports).

If an upgrade was partial (or rolled back halfway), you can end up with:

• MSI registration updated (shows newer/older “product version”),

• but some binaries (Pulseway Manager / Service / shared MM.Framework DLLs) are from a different build.

Your log already proves you have mixed components, because a 9.24 service build is trying to call a method that isn’t present — meaning an older or wrong MM.Framework is sitting somewhere in its load path.

3) Could Pulseway have messed this up during the 9.24 rollout?

Yes, that’s a plausible root cause — but the more precise statement is:

Something caused this machine to end up with an inconsistent agent install (partial upgrade, failed repair, AV quarantine of a DLL, interrupted update/reboot timing, or “self-heal” MSI behavior).

The log supports “bad/partial install state” because:

• The service throws the MissingMethodException at startup

• And 3PP repeatedly fails trying to install SMClient with the same error

That’s not “a bad patch policy” or “3PP configuration” — it’s a broken dependency chain.

4) The most likely causes (ranked)

1. Interrupted/failed agent upgrade (rebooted mid-upgrade, service restarted early, etc.)

2. Stale/old DLL left behind in C:\Program Files\Pulseway\ or a shared location, so the service loads the wrong MM.Framework.*

3. AV/EDR quarantine of a single DLL (you get a “new exe + old libs” scenario)

4. Multiple Pulseway installs/leftovers (older “MMSOFT Design” folders still present and being referenced)

5) What I’d do (fastest path to green)

Best fix: do a clean repair reinstall of the Pulseway agent (same build you intend to run). That forces all assemblies to line up and usually stops this instantly.

If you want to prove it before reinstalling, check these on the endpoint:

• In C:\Program Files\Pulseway\ and ...\Patch\servermodule-15-12\ look for MM.Framework*.dll and note file versions/dates.

• Confirm whether there are multiple copies of MM.Framework DLLs in different subfolders (the loader can pick up the wrong one).

6) One more clue in your log: SMClient is being pulled from a 9.21 path

It’s downloading SMClient from a URL containing /updates/9.21/.../smclient.zip

That’s not automatically “wrong” (vendors sometimes host modules separately), but it’s another hint that module compatibility depends on correct framework libraries on the endpoint — and yours aren’t.