NoVirusThanks OSArmor: An Additional Layer of Defense

If you select "exit GUI" NoVirusThanks OSArmorDevSvc is still running and OSA still
protecting your system. No notification popups will show if something gets
blocked, but the event is still recorded in the log file.
The process OSArmorDevUI.exe will stop running when you select "exit GUI" from
the icon menu. Maybe I'm misunderstanding your post.

 

I stand corrected and you are right.

Prior to uninstalling and reinstalling OSA, the "Exit GUI" behavior was as I described. However after re-installation as I recently did, the behavior is as you described. This confirms my findings that install of new version of OSA "on top" of old version can cause issues.

 

Again as far as I am aware of, the only parent process that should be spawning a winlogon.exe child process is smss.exe.

Ref.: https://digital-forensics.sans.org/media/DFPS_FOR508_v4.6_4-19.pdf

 

Well I don't know what to say, other than two legitimate Microsoft-signed processes came into play when trying to log back in, and there was no influence by a foreign, malicious script or anything involved.

On another note, it's a new record for me; eight consecutive days (after upgrading to v20H2 no less) with no failures from OSArmorDevSvc in starting up. The previous record was seven days. I'll keep my fingers crossed.

 

Well it happened again today after a system restart. OSArmorDevSvc service not starting. And this occurred subsequent to a new OSA install.

My theory is this is related to OSA driver updating activities. One strong possibility is your AV scanner; Eset in my case. Eset sees those .sys files have been modified and starts scanning them. While this is going on, it prevents OSA from properly starting OSArmorDevSvc service. I do know I don't want to exclude these files from Eset scanning. The solution is for OSA to stop modifying those drivers. I don't know why they are doing this in the first place since I have never seen this type of driver updating occurring previously on any software I have ever used.

 

+1 I have used OSA plus Kaspersky and OSA plus Eset without having any issues whatsoever.

 

I decided to get to bottom of this OSA not starting issue by taking "the bull by the horns." Here's the tests I performed:

1. Added Eset real-time scanning exclusions for OSA two driver .sys files. Result - didn't help.

We can also rule out Eset as a possible culprit although its ELAM driver scanning at boot time could still be a factor.

2. Changed OSArmorDevSvc service 1st and 2nd Failure Recovery options to "Restart the service." Result - didn't help.

3. Changed OSArmorDevSvc service startup mode to Automatic - Delayed. Result - that worked!

The glitch is it took OSA 30+ seconds after desktop initialized to start. But it did eventually start. Of note is if you're deploying Win 10 fast startup mode, OSA starts immediately since the OSArmorDevSvc driver is already loaded. I guess this is the best work around for the time being versus manually starting the service via Control Panel option.​

 

@itman

Posted on Wilders forum:

What processes should be allowed in my Antivirus or HIPS?
You should allow or exclude all .exe and .dll files located in the following folders:
C:\Program Files (x86)\NoVirusThanks\NVT License Manager\
C:\Program Files\NoVirusThanks\OSArmorDevSvc\
Make sure they are allowed or excluded in your other security software.
Then try to restart the PC and if problem persists, try to uninstall and re-install OSArmor.

Are you using any exclusions for OSArmor in Microsoft Defender?

 

This is a nice result; surely it might help others running ESET and OSArmor. I would not accept OSArmor in the Automatic--delayed mode; it's either start with Windows or nothing. It seemed to be a frustrating problem until you solved it.

 

@itman

it's nice you seem to have found a solution for your specific case, and thank you for sharing this, but at least in my case (not trying to make this about me BTW ) I don't run ESET, and I had numerous of these failed startups, so it's definitely not specifically an issue caused by ESET, and I realize you didn't imply that, but maybe it's related to antivirus, as I do run Windows 10 Defender, but then why in my case has it been so highly random and infrequent? Anyway, it's been a personal record nine days since I upgraded to 20H2 and no OSArmorDevSvc startup issues yet Will post if it happens again.

This might be the solution. Just maybe

 

The problem with these recommendations is they contradict OSA's own recommendations. Per OSA Help-FAQS:

I made these exclusions to Eset immediately after OSA initial installation.

I also do not feel it advisable to exclude OSA directories en-mass from AV real-time scanning.In any case, none of the third party exclusion recommendations would have anything to do with OSArmorDevDRv.sys loading issues at system restart time.

As far as this OSA startup issue at system restart occurring w/Windows Defender, I again suspect its ELAM driver is the source. The problem with WD is it does not have a user configurable HIPS. Pre-defined ASR rules are it.

 

I'm still using the freeware version of OSA and this has never happened to me, it always starts correctly. So it might be a problem with newer versions of OSA and perhaps you guys are also using newer versions of Win 10.

 

The same was happening to me previously. However, Eset recently updated its ELAM driver. Since then, the non-starting of OSA at system restart was consistent. This startup inconsistency does make debugging the issue difficult.

 

Yeah it's been difficult for sure to find the root cause. Andreas was working with me for over a week a while back through pm, and he wasn't able to narrow it down in my case. Certainly not for lack of effort.

 

I just installed Optional Cumulative Update KB5001649 and after the required restart OSA failed to start.

 

There must be a way NoVirusThanks can come up with a debugger to find out why the failed startups happen.

 

I downloaded NVT's own driver verifier utility "to get a grip" on what's going on. First, OSA's drivers load near to the bottom of this list. This negates my prior statement that OSA's self-protection is device driver. Next is that OSArmorDevDv.sys loads prior the self-protection driver.

-EDIT- The following is a revision from what I originally posted.

I found the OSArmorDevSvc startup fix and it has nothing to do with OSA driver loading , AV ELAM driver blocking of drivers, or the like as I originally posted and have since deleted.

To begin, this is a case in point in not to perform multiple system modifications at the same time when testing. I previously had set OSArmorDevSvc to Automatic - Delayed. Later I changed it back to Automatic and at the same time create an Eset HIPS rule to allow OSArmorDevDrv.sys to load. When I rebooted multiple times w/OSArmorDevSvc always starting, I falsely assumed that the Eset HIPS rule creation was the solution. It wasn't.

Here's what fixed this issue. When OSArmorDevSvc was set to Automatic - Delayed, the following highlighted reg. key value was created with a value of "1":



When I reset the service back to "Automatic," the value was set to "0." All this is explained here: https://www.winhelponline.com/blog/service-startup-automatic-vs-automatic-delayed-start/ .

What isn't fully explained in the article, or anywhere else it appears, is the presence of a DelayedAutoStart service reg. key value set to 0 with the service start type set to "2" (Automatic) will force start the service.

 

As to what is the real problem with OSArmorDevSvc service startup, I suspect it has something to do with the WOW64 value used as shown in the above OSArmorDevSvc reg. key screen shot. I have never seen that parameter used before. There is an interesting discussion its use here: https://groups.google.com/g/microsoft.public.win32.programmer.kernel/c/3g0_49jH59M. Also when used, its value is the following:

which is clearly not the case for the OSArmorDevSvc reg. key WOW64 value.

Ok. Here's a Win 10 specific reference: https://docs.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details. Set Global Hooks - interesting.

 

I'm probably way off, but is it possible that it has something to do with MBR vs UEFI? I ask because I have only noticed OSA not starting on my UEFI machine.

 

My PC is MBR. So the answer to your question is no.

 

Mmm, OK.

 

I am pretty sure I have found the "culprit" for OSArmorDevSvc not starting at system startup time. It is poor app design on NVT's part. Let's get into the "nitty gritty."

@Rasheed187 previously posted he has no issues in this regard since he is still using the free version of OSA. I am sure this holds true for anyone still using the free version of OSA. Why is there no issue? The free version doesn't include OSA license validation processing. I also believe anyone installing the paid versions of OSA for the first time will also not have any issues. Also and important is if after installing the paid version and allowing auto updating of OSA, they will have no issues with OSArmorDevSvc not starting at system startup time.

I believe the issue with OSArmorDevSvc startup manifests when either a new paid version is installed "over top" of an existing OSA paid version. Or as I did, OSA is uninstalled via Control Panel -> Programs option but OSA License Manager is not uninstalled prior to re-installing OSA.

What causes this OSArmorDevSvc not starting at system startup time issue? Refer back to my posted OSArmorDevSvc registry parameters screen shot. Now take a look at the value that exists in the WOW64 parameter. It appears to be a base displacement calculated address. A hook is being established between the OSArmorDevSvc.exe process and the NVTLicenseManager.exe process. If the hook cannot be established , the service creation processing errors out resulting in the service not starting. As long as both processes were installed at the same time, there will be no issue in regards to this hooking activity and OSArmorDevSvc not starting at system startup time.

Time NVT redesigns this "flaky" license validation processing it is using.

 

@itman

NVT License Manager is a complete separate and "decentralized" product: it is used only to manage the licensing by OSArmor, Win Update Stop and will be used by all other commercial products that we'll release. It is a 32-bit application (both the service and the activator GUI app), so it is normal that on 64-bit OSs it may write data on WOW64 registry key. The problems you reported should not be related to NVT License Manager, however will run some tests for additional verifications and will report back in case.

When the OSA icon is not present in the system tray, it may also indicate that OSA GUI was started in a wrong user session by OSArmorDevSvc (this has happened in Windows Server 2019 with RDP role, but worked fine without RDP role). Or it may also indicate that OSA GUI failed to run in the system somehow. But in both cases, if OSArmorDevSvc.exe is running, then its protection is active. Your case may not be related to the two examples above, but just wanted to add additional possible cases.

I will install W10 20H2 + ESET + OSA in a few VMs and will run some tests to see if there can be issues with ESET. Theorically there should not be because OSA files are all signed, including the driver that is co-signed by MS and should be auto-allowed by ESET protection/HIPS. Anyway will report back here if I find something.

The 4 cases reported with this OSA v1.5+ startup issue are definitely strange, in my tests I was not (yet) able to reproduce them. If things will not be sorted out shortly, I will evaluate the possibility to create a debugging version of OSA to help understand what can be the cause. As additional information: 2 users reported this issue time ago also with OSA old version v1.4 but somehow it got fixed after some Windows Updates got installed.

I read your posts and you reported that you didn't have these OSA startup issues recently, can you confirm this? Or has it happened again?

Correct, as per the FAQs:

@Rasheed187

Yes I will take a look and see what we can do for that DPI issue too.

@wat0114

Thanks for updating about your situation, still no OSA startup issues after upgrade to Windows 10 v20H2?

Another user has reported the same thing: after a clean install of Windows 10 v20H2 he noticed no more OSA startup issues.

Not sure if it is related, but just wanted to report this too.

 

Besides verifying that OSArmorDevSvc hasn't started via Control Panel -> Services option, I also tried to access OSA via desktop icon; not the toolbar icon since it didn't exist, and received a notification that OSArmorDevSvc wasn't running.

So in all my cases when the OSA desktop toolbar was not present, OSA was indeed not running.

 

Yes, it's 100% repeatable at every system restart, OSArmorDevSvc service is not started which results in OSArmorDevSvc.exe not starting.

The registry fix I posted does work for me so I am not currently being impacted by the issue.