Replies

Bumped into this recently: while running Windows Defender scans, a legacy Windows 8.1 system (running flawlessly with zero security incidents, no significant issues over the years and still up for the job and tasks and goals it was set up and meant for – which is quite remarkable comparing to the effort put in dealing with, and fixing, a rather long list of issues while managing “modern” Windows 10/11 WaaS systems) suddenly began showing up the yellow warning symbol and the alarming message

“Preliminary scan results show that there might be malicious or potentially unwanted software on your system”

but the scan always ended with a “green” status reporting a “safe” machine, with 0 results (no malware findings at all). In every single scan, roughly at the very same point of the scanning progress, the warning message came up but, in the end, there were no quarantined contents, history was clear (no detections), there were no defined exclusions involved and – what’s more annoying – there were no useful log contents to help.

If that wasn’t odd enough, disk cleanups and system restarts made no difference: it was a sticky, “persistent” situation of a “false positive” that refused to go away, no matter what (and yes, that was confirmed to be the case after spending a couple of hours extensively applying advanced malware scanning techniques that ensured, with a high degree of confidence, that the system in question was, indeed, “clean” and that there were no active infections whatsoever).

It turns out there’s a reasonable explanation for this odd behavior:
https://learn.microsoft.com/en-us/answers/questions/326108/mar-17-21-msert-detects-items-during-scan-but-at-e

Rob Koch’s post (here quoted by Andy David, replying to a similar scenario when running the MSERT standalone tool – one of the many Microsoft security products that, like Windows Defender, share the same common antimalware platform) is enlightening but doesn’t tell you the whole picture, neither does it pinpoint exactly WHY or HOW this scenario might happen. It also doesn’t tell you how to FIX it, so here’s the deal (based merely upon my observations and assumptions and how I was able to workaround the issue and fix it)…

1. Consider a legacy Windows 7 system running Microsoft Security Essentials (or, in my case, a legacy Windows 8.x system running the same rebranded and upgraded Windows Defender product that, incidentally, never had any malware detection before) with the Settings > MAPS option configured to be either ‘Basic membership’ or (as it was the case) ‘Advanced membership’.

2. While executing an OFFLINE scan, the yellow warning symbol is shown and the “Preliminary scan results” message appears. In the end, a PuP (Potentially Unwanted Program) is found.

• At this point, Defender has a copy of the “suspicious fragment” that triggered the warning and lead to the PuP detection. Because the MAPS option was set accordingly, if there had been internet connectivity when the detection occurred, or roughly at 95% of the progress accordingly to Rob Koch’s post, the fragment should have been sent directly to Microsoft, so that the MAPS servers would analyze it and return further information about its nature (confirming if it was, indeed, a known piece of malware or a possible unknown strain of malware that should be further analyzed and included in upcoming antimalware signature definitions). This “cloud protection” feature implementation is not uncommon, it’s just how modern security products work.
  .
• Defender’s MAPS option is roughly equivalent to the “heartbeat” feature of both the Malicious Software Removal Tool (MRT) and Microsoft Safety Scanner (MSERT) standalone removal utility. All the three products set their own Registry REG_DWORD value that determines if any detection findings shall be sent, or not, to Redmond:

  ; Microsoft Security Essentials [Windows 7] / Windows Defender [Windows 8.x]
  ;
  ; If the 'SpyNetReporting' REG_DWORD is set to 0,
  ; Defender should not submit any findings to Microsoft MAPS servers
  ;
  [HKLM\SOFTWARE\Microsoft\Microsoft Antimalware\SpyNet\]
  [HKLM\SOFTWARE\Microsoft\Windows Defender\SpyNet\]
  ;
  ; 0 = I don't want to join MAPS <- Privacy-minded preferred option
  ; 1 = Basic membership
  ; 2 = Advanced membership
  ;
  "SpyNetReporting"=dword:00000000
  ;
  ; Microsoft Malicious Software Removal Tool (MRT) / Microsoft Safety Scanner (MSERT)
  ;
  ; The Registry key and the 'DontReportInfectionInformation' REG_DWORD might not exist,
  ; which is the default and equivalent to having the REG_DWORD set to 0
  ;
  ; 0 = Send the detection findings to Microsoft ("heartbeat" report)
  ; 1 = Do *NOT* send the detection findings to Microsoft <- Privacy-minded preferred option
  ;
  [HKLM\SOFTWARE\Policies\Microsoft\MRT\]
  [HKLM\SOFTWARE\Policies\Microsoft\MSERT\]
  "DontReportInfectionInformation"=dword:00000001

• The system’s MAPS option is set to submit the “suspicious fragment” (SpynetReporting REG_DWORD > 0). However, because the user is OFFLINE, Defender was unable to do so: instead, it keeps the “suspicious fragment” in a local “cached” folder. Presumably, once the internet connectivity is (re)established, the fragment may be queued and sent to the MAPS servers – either automatically or, eventually, when the next scan happens.

3. Realizing the detected PuP is NOT a malware infection, but rather a false positive scenario triggered by a specific tool that the user had been temporarily using for troubleshooting purposes (case in point: NirSofer’s WirelessNetView), the user not only dismisses the question and accepts Defender’s automatic action (the tool was put into quarantine) but he also uses the ‘Remove all’ button in the ‘History’ tabsheet to clear the scanning history and remove the item from quarantine (effectively confirming the tool’s deletion).

• At this point, the machine is still OFFLINE but Defender is smart enough to honor its MAPS settings: therefore, despite being instructed to clear its scanning history and quarantined contents, the “suspicious fragment” that triggered the PuP detection still exists, and will be kept. The “cached copy” of it (which is now an orphan reference to something that doesn’t exist anymore, because the tool was deleted) will supposedly be submitted to the MAPS servers once the internet connectivity is (re)established, or the next scan happens. But here’s the catch:

4. The user also realizes the MAPS option in the ‘Settings’ tabsheet is set to ‘Advanced membership’ but, because he recently had middle management “security training” and had received, and read, internal company emails alerting to “privacy issues” that could arise from inadvertently having software misconfigured to “disclose corporate privileged information” he promptly changes the MAPS setting to ‘I don’t want to join MAPS’.

I won’t digress about the user’s decision. The important thing here is, what should Defender do? Honor the MAPS option that had been previously set (and keep the cached “suspicious fragment”, now an orphan reference, for later submission) or adapt and adjust to the new MAPS option (and remove the “suspicious fragment”, since the now chosen MAPS option clearly states that “No information will [shall] be sent to Microsoft” anymore)? I’d say BOTH:

• If the system restarts now it is acceptable that, after a reboot, the new MAPS option should be honored and the orphan, “suspicious fragment” leftover shall be removed (similarly to what happens in the legacy software installation process, requiring a reboot to replace drivers, reapply settings and so on);
• If the system doesn’t restart yet and internet connectivity is (re)established in the meantime, it is also acceptable to assume that the old MAPS option should still be honored and the “suspicious fragment” should still be sent anyway because, at the time of its detection, the MAPS option was set to send it to Microsoft (and, it might be worth noting, that an additional ‘SubmitSamplesConsent’ REG_DWORD was also set to 1). Therefore, it is acceptable that the user’s decision otherwise shall only be taken into account from the time it was changed onwards and that the user’s decision doesn’t apply to the previously detected items. If the submission doesn’t happen automatically, it is also acceptable that it may happen at the next scan. Either way, internet connectivity must exist, so that the item can be submitted to the MAPS server, and only then – after submitting that “fragment” – the ‘SubmitSamplesConsent’ REG_DWORD can also be set to 0, honoring the user’s current decision (MAPS option set to ‘I don’t want to join MAPS’ [anymore]).

But, wait: what if the system DOESN’T restart yet, internet connectivity is (re)established and Defender is updated with new antimalware signature definitions before it has a chance to submit the “suspicious fragment”?

In that scenario, it is fair to assume that a “bug” MIGHT exist in the legacy Win7/8.x Defender’s interface that, when applying the new antimalware signature definitions corrupts somehow the orphanized “suspicious fragment” state and that cached, orphanized “suspicious fragment” becomes a “zombie” that might be repeatedly read and re-interpreted as a “preliminary scan result”, consistently and incorrectly triggering a warning message that refers to something that doesn’t even exist anymore!

In my case, that assumption was enforced by the fact that doing the obvious (changing back the MAPS option to ‘Basic membership’ or ‘Advanced membership’, connecting to the Internet and executing a scan so that the fragment could be submitted and subsequently removed from the local cache) didn’t seem to work, either. Not even after multiple system restarts and MAPS option changes in between. Whatever the reason was (probably related with the order in which the user actions occurred, the internet connectivity was (re)established, the new signature updates were applied or even the very nature of those specific signature definitions – eventually an intermmediate beta, buggy “delta” version), something went wrong in Defender’s interface: a glitch in the expected workflow that prevented the product from ever submitting the orphanized “fragment” to the MAPS server or removing it from the local cache – leaving that “fragment” indefinitely lying as a “zombie” leftover that kept triggering a misguiding warning to a non-existent “preliminary sign” of a non-existent malware infection!

Thus, I ended up fixing the situation by rebuilding Windows Defender’s internal “cached” history (a word of caution applies here: be advised not to do that unless you’re absolutely sure that the machine isn’t infected by malware – otherwise, you might be doing more harm than good. When in doubt, always seek experienced help). Here’s how:

1. Boot from a rescue disk (or a Linux live system that gives you root access to the filesystem) – “Safe Mode” won’t do here.
   .
2. From an elevated prompt, rename the history folder (as a convenient and temporary backup to rollback things up, if necessary) and create a new one, with nothing but the minimum, required subfolder structure and the main .bin control file(s):

   cd /d "C:\ProgramData\Microsoft\Windows Defender\Scans"
   ren History History.BAK
   mkdir History\CacheManager
   copy History.BAK\CacheManager\Mp*.bin History\CacheManager /v /y
   mkdir History\Results\Quick
   mkdir History\Results\Resource
   mkdir History\Service
   mkdir History\Store

3. Reboot and perform a Quick scan. Wait for it to finish: if the system is indeed “clean”, the yellow warning symbol and the “Preliminary scan results” message shouldn’t appear anymore. For completeness (if you want to double check and make sure all’s clean and well) you may wish to run a Full scan, too.
   .
4. From an elevated prompt, the old folder can now be safely removed:

   cd /d "C:\ProgramData\Microsoft\Windows Defender\Scans"
   rd /s History.BAK

That’s it. Hope it helps. 😉

1 user thanked author for this post.

DrBonzo

No, we’re just talking about the predefined (Windows) system folders and shortcuts (see above).

1 user thanked author for this post.

DrBonzo

The whole point of moving the shortcuts merely reflected my own, personal preference – one way to keep things “clean” (like you, I too prefer to have shortcuts organized into multiple sub-folders, having no shortcuts at all at the “root” level) but I hear you: you have a very good point there – and yes, it is actually a much better suggestion than my (somewhat clumsy) approach.

Indeed, it is probably better to leave the original system sub-folders and shortcuts quiet and alone at their default, predefined locations and just hide them (with an attrib +H <folder> or attrib +H <shortcut> command, from an elevated prompt) so that they won’t appear (be visible) in your customized toolbar – and make copies of those items you want to use into your customized toolbar. Something (roughly) like this:

cd %ProgramData%\Microsoft\Windows\Start Menu\Programs
mkdir Windows
xcopy /E /I Accessibility Windows\Accessibility
xcopy /E /I Accessories Windows\Accessories
xcopy /E /I “Administrative Tools” “Windows\Administrative Tools”
xcopy /E /I “System Tools” “Windows\System Tools”
xcopy /E /I “Windows PowerShell” “Windows\Windows PowerShell”
attrib +H Accessibility
attrib +H Accessories
attrib +H “Administrative Tools”
attrib +H “System Tools”
attrib +H “Windows PowerShell”
attrib -H *.lnk
xcopy *.lnk Windows
attrib +H *.lnk

Visually, it works like a charm… Next month I’ll let you know if it also works out well and allows the monthly updates to install flawlessly in those few Windows 8.1 legacy systems I’m maintaining. Thanks for the tip! 😉

Help for Windows 8.1 x64 folks out there – updated, no issues so far:

1. Keep in mind there’s a new SSU this month, thus manually download KB5014025 first, install it and reboot (for good measure).
2. Let Windows Update install KB5014011 (or manually download it from the MS Catalog and install).

Now here’s an additional tip for Windows 8.1 (eventually applicable to Windows Server 2012 R2) folks: if the monthly update fails to install with cryptic errors such as 0x80070002 (WIN32: ERROR_FILE_NOT_FOUND) there might be a good, but less-known reason for that. Keep reading.

You see, some people choose to “customize” their %ProgramData%\Microsoft\Windows\Start Menu\Programs folder by moving some of the system shortcuts from their default locations (for e.g. grouping them all into a ‘Windows’ sub-folder) and create a ‘Programs’ toolbar on the taskbar: it might look weird to do that but it is, in fact, a very simple, but handy way to have your shortcuts at hand, similarly to having the Windows 7 “Start” button, just by using the system resources (without any need for additional software).

Problem is, the setup installers “expect” some, if not most system shortcuts to be present in their default locations: if they aren’t, installation might fail and throw those cryptic errors. This is a rather common cause of installation failures for Windows 10 (therefore, a quick and dirty way of preventing those “errors” from happening, if you knew that in advance, would simply be to move back the system shortcuts to their default locations, install the update and restore the system shortcuts back to your customized locations) – one that didn’t affect or manifest itself on Windows 7/8.x until very recently and something that people typically “fix” (blindly and unaware exactly of “why” it works) by “restoring the system health” with a dism /Online /Cleanup-Image /RestoreHealth command (or, in Windows 7, with a sfc /scannow command).

Thus, to sum things up: if you happen to experience trouble updating your Windows 8.1 (and, eventually Server 2012 R2) systems, the fail-safe approach is usually to manually update:

1. Confirm that your system shortcuts at %ProgramData%\Microsoft\Windows\Start Menu\Programs are all there, at their default locations (if they aren’t, move them back there or restore them with a dism /Online /Cleanup-Image /RestoreHealth command);
2. Download KB5014025 (the latest SSU) and KB5014011 (2022-05 monthly update) from MS Catalog.
3. Install KB5014025 (the latest SSU) first. Reboot afterwards (you don’t have to, but just in case – for good measure).
4. Install KB5014011 (2022-05 monthly update) and reboot.

Additionally (depending on your system configuration, preferences and needs) you might also let Windows Update install (and/or manually download and install yourself) the KB890830 (MSRT) and KB5013870 (.NET Rollup) updates.

Hope it helps. 😉

3 users thanked author for this post.

Steve, abbodi86, DrBonzo

@abbodi86, you’re absolutely right. Thank you!
Last week was a busy one and I didn’t pay enough attention… my bad. I went back to that system over this weekend to figure out what happened and the culprit seem to have been (might have been?) a hardware driver update (indeed, uninstalling KB5009624 and KB5009721 was not the same as restoring back the Dec 31, 2021 image: they were both installed on Jan 6, 2022 but that driver had been automatically installed on patch Tuesday [Jan 4, 2022] but went unnoticed and that’s probably what caused the unexpected interaction that lead to the missing runtime library situation).
Updating the C++ runtime libraries “fixed” the situation, yes, but the situation itself wasn’t caused neither by the KB5009624 or the KB5009721 roll-up updates. My bad, sorry.

2 users thanked author for this post.

abbodi86, Microfix

@NTDBD, the definitions for Microsoft antimalware products are available for download at https://www.microsoft.com/en-us/wdsi/defenderupdates (for Windows 7, you’ll probably want to bookmark the Microsoft Security Essentials 64-bit link).

I’ve posted a few more useful details about getting the latest engine (point 2) and the latest definitions (point 3) here and here (update on point 3).

Hope it helps. 😉

Thanks for sharing, @Intrepid. Just out of curiosity, may I ask if any of your ten workstations also had that exact same version (v14.0.24212) of the Visual C++ 2015 runtime libraries installed?

[Speccy]

While managing a fully patched and fully functioning (as of Dec 31, 2021) Win8.1 Pro x64 system, after the January 2022 updates (KB5009624 monthly roll-up, KB5009721 .NET Framework roll-up) suddenly “something” got broken: pieces of software and core parts of the O.S. itself (e.g. Computer Management) began throwing an error complaining about the (now) missing ‘vcruntime140_1.dll’ library.

Rolling back to a previous backup image (as of Dec 31, 2021) restored the system stability (got the missing library back and everything else working normally, again). Can’t tell for sure if the culprit is either KB5009624, KB5009721 or an unexpected interaction between the two (haven’t had time to try uninstalling only one of them in turns, to be sure) but uninstalling both updates also worked (same as restoring back the system to the Dec 31, 2021 backup image).

I am guessing here that Redmond messed up (again) while packaging the updates and used the wrong versions of the Visual C++ Runtime libraries, because another option that also worked out well was to keep both updates (KB5009624 and KB5009721) installed and simply update the Visual C++ 2015 runtime libraries (as of Dec 31, 2021 that Win8.1 system had v14.0.24212 installed) to v14.30.30704, which were the latest available redistributable packages (signed October 5, 2021) here (“Visual Studio 2015, 2017, 2019, and 2022” section):

https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

For now I am not installing the optional KB5010794 update yet (I’ll just wait for the February updates) but I am assuming that this optional update will do exactly that (update the Visual C++ 2015 runtime libraries) because as I am writing this (Jan 20, 2022) the above webpage is now offering v14.30.30708 (signed January 6, 2022) of the Visual C++ 2015 runtime libraries… 😉

Just my 2 cents,

• This reply was modified 1 year, 8 months ago by Speccy. Reason: The site doesn't like UNDERLINED text anymore? And editing and submitting back the post will also DELETE IT? What the heck?

4 users thanked author for this post.

deuxbits, DrBonzo, Microfix, 7ProSP1

[Speccy]

Minor update to point 3 in the above, previous post… meanwhile, the direct links were updated to also include the engine version:

hxxps://definitionupdates.microsoft.com/download/DefinitionUpdates/VersionedSignatures/AM/<DEFS_VERSION>/<ENGINE_VERSION>/x86/mpam-fe.exe
hxxps://definitionupdates.microsoft.com/download/DefinitionUpdates/VersionedSignatures/AM/<DEFS_VERSION>/<ENGINE_VERSION>/amd64/mpam-fe.exe
hxxps://definitionupdates.microsoft.com/download/DefinitionUpdates/VersionedSignatures/AM/<DEFS_VERSION>/<ENGINE_VERSION>/arm64/mpam-fe.exe

For e.g. the direct link to the current 1.353.736.0 64-bit definitions (and the current 1.1.18700.4 engine) is:
https://definitionupdates.microsoft.com/download/DefinitionUpdates/VersionedSignatures/AM/1.353.736.0/1.1.18700.4/amd64/mpam-fe.exe

• This reply was modified 1 year, 10 months ago by Speccy. Reason: Fixed bold tags

It was. But because AI and ML were already being developed for a few years and coming in full-mode, despite some cautionary tales on the road Redmond took Cortana to the next level and that’s the whole point of what Windows turned out to be nowadays: a nurturing environment for the rise of an AI aiming to “function in an open-ended continuous learning process, being able to ethically apply common sense and infer causal reasoning”.

We’re not there yet but that’s really the big picture here (a promising or scary one, in many ways, depending on how you look at and think about it) and something to be aware of that we’ll all have to deal with, one way or the other, in the upcoming years.

P.S. – To the forum moderators’ censoring fast fingers out there, sorry for the apparently off-topic reply (?) but it really is an honest attempt to contribute to the thread, in finding an answer to the initial question [The Next windows: What is it? We don’t really know].

Maybe unrelated, but the official teaser (at 11 a.m. Eastern Time) refers to a live stream event and, accordingly to the Microsoft Reactor website at that very same moment, on a different time zone (4 p.m. Central European) a live stream about AI and Accessibility is scheduled for Stockholm.

Quoting:

What is this session about?
Microsoft has infused AI into Office 365 applications to support accessibility. Whether it’s Speech and Language AI providing live subtitles in PowerPoint, or Vision AI generating alt text for images, everyone can benefit from accessible features.

Who is it aimed at?
All developers who are interested in building in accessibility to their apps using Azure Cognitive Services.

Why should I attend?
To learn how to design, develop, debug, and deploy an app on Azure to demonstrate the power of AI for Accessibility. For more on this series, visit https://aka.ms/HigherEdSeriesPg

Speaker info:
Stephen Howell | Academic Program Manager
Stephen has 22 years’ experience in software engineering, lecturing, program management, and the education industry. He is currently the Academic Program Manager for Microsoft Ireland.
In this role he advocates for STEM skills at K12, computer science skills to higher and further education customers, and digital transformation to government educational agencies.

Stephen is an advocate for STE(A)M, Autism & ADHD awareness, Gender Diversity in Tech, and increasing accessibility in technology for all. He is the Diversity and Inclusion Council Accessibility Pillar Lead for Microsoft Ireland (from July 2019).

He is in final year of a PhD in SMARTLab, University College Dublin on Inclusive Design and Creative Technology Innovation, where his research focuses on Computational Thinking and Kinesthetic Learning.

Meanwhile, a few things happened since 2018…

This article (published today) is a useful insight to put things in perspective and sums it up nicely: the so-called “cloud protection” feature may be turned off without adversely affecting or impacting the overall performance, protection and disinfection capabilities of the product. Privacy concerned users might want to consider that aspect because similar cloud-based protection features do exist, too on the reputable and US friendly, sanctioned and approved security products from most other vendors.

Recent posts from Kaspersky (admittedly biased) might also help to draw a clearer picture of how the legitimate, but unproven claims are being dealt with.

https://usa.kaspersky.com/transparency-center
https://usa.kaspersky.com/about/press-releases/2021_na-kaspersky-ranked-top-in-canalys-channel-satisfaction-benchmark-for-second-year
https://usa.kaspersky.com/about/press-releases/2021_kaspersky-finds-nearly-half-of-companies-prohibit-sharing-threat-intelligence-findings-with-professional-communities
https://usa.kaspersky.com/about/press-releases/2021_na-kaspersky-ranked-top3-cybersecurity-solution-in-81-of-benchmarking-tests
https://www.kaspersky.com/top3

Disclaimer: I’ve no affiliation whatsoever with Kaspersky and I’m not trying here to “advertise” their product (moderators, feel free to edit my post and remove the above links if you consider they don’t add any value to the post and/or by posting them I’m unwillingly breaking in any way the current rules, norms and guidelines of what can or cannot be posted on the website and the forums – I don’t think so and I certainly hope not as it’s not my intention, at all, to do that). Like Alex I just don’t buy that things are as black and white as we’ve been told: there are many shades of grey and things to consider (context, political an economic interests, product settings and use cases, etc).

1 user thanked author for this post.

Alex5723

Cool. Glad to know it worked well for you, Rick. 🙂

You’re welcome. 🙂

TeamViewer’s File Transfer works well and is perfectly fine (encrypted, peer-to-peer secure communication) as long as you have a stable UDP connection to support transfer speeds of up to 200 MBps. Otherwise, it will fallback to TCP and can only reach 120 Kb/s (on slow network connections even SFTP might be considered a better alternative).

I must say I haven’t used Send Anywhere thoroughly (only once, briefly) but it sure looked interesting and worth mentioning here as an alternative to try: if you do, please report back and let us know how that went. For the sake of transparency (in case anyone has a problem with that) it might be worth mentioning it comes from a South Korean start-up based in Seoul:

https://send-anywhere.com/about

Interesting tool (and the concept loosely “right”) but for now it seems a bit half-baked at the moment and, more importantly, poorly documented (security through obscurity is definitely not on the wish list of privacy-minded folks).

On an isolated VM I allowed the stub to download the 9.56Mb setup and then did a few quick, straightforward and simple offline experiments:

oofd ?
oofd /add C:Temptest.txt
oofd /delete C:Temptest.txt
oofd /settings

Looking at the (hidden?) settings, both the default connection server address ( wss://signal.file.direct ) and the API server address ( https://api.file.direct, redirecting to https://www.oo-software.com/en/filedirect ) appear to confirm the assumption that the tool might be using WSS on HTTPS and standard secure encryption protocols (AES, Camellia, etc) to communicate with the O&O servers and support its core functionality (establish a securely encrypted point to point connection). The other setting suggests the (optional?) use of a STUN/TURN Server and WebRTC communication.

Proper documentation, further analysis of the tool and closer inspection on its behavior and the network traffic it generates would be useful and enlightening. IMHO the response “tone” (short, abrupt) of the support email you received, added to the fact that this is a proprietary, closed (not opensource) software doesn’t help to build user trust on it, either.

In regards to possible alternatives to O&O FileDirect, although also proprietary consider taking a look at Send Anywhere:

https://send-anywhere.com/product

The current version (product/file version 20.8.200955/20.8.4347, build 1253, digitally signed Aug 20, 2020)) is less lightweight both on size and memory usage but on the plus side it seems a more mature product (cross-platform, uses the Electron framework) with a few more, interesting options (check the settings), a User Guide and some available online documentation:

Support (KB):
https://support.send-anywhere.com/hc/en-us

Notices:
https://support.send-anywhere.com/hc/en-us/sections/201021268-Notice

1 user thanked author for this post.

Rick Corbett