Shadow Defender Service and GUI terminated

[Mr.X]

After installing ReHIPS today and activating it, Shadow Defender Service and GUI were terminated. Restarted my PC, SD starts as usual and again terminated somehow, along with its service too.

[matra]

Me too!

[fixer]

Thank you for your report, we'll look into this issue and fix it.
Could you tell me exact Shadow Defender version so we could reproduce it?

[matra]

My is Version 1.4.0.665

[Mr.X]

My is Version 1.4.0.665

Same.

DL

Code Select Expand


http://www.shadowdefender.com/download/SD1.4.0.665_Setup.exe


[Mr.X]

Any news on this?

[fixer]

It may take some time, but don't worry, we've got this issue in our TODO list and if it's a bug on our side, it'll surely be fixed in 2.3.0 release.

[aDVll]

Assuming you might have lockdown mode did you try adding Shadow Defender digital signature in trusted vendor list in case something gets blocked before gui is there to show an alert?

[Mr.X]

Assuming you might have lockdown mode did you try adding Shadow Defender digital signature in trusted vendor list in case something gets blocked before gui is there to show an alert?

It's a fresh Windows 10 install. Last program was ReHIPS.

As soon as it finished its install routine, SD gui disappeared an its service too. Consequently I disabled ReHIPS protection (red).

Restarted the machine, all progs are loaded as expected including SD gui, next after a few seconds it vanishes along with its service.

What I'm trying to say here is that if ReHIPS protection is disabled it shouldn't interfere with anything, yet it's doing so to SD somehow.

[aDVll]

Ok didn't get the part that it does it even when you disable rehips.

[Mr.X]

Ok didn't get the part that it does it even when you disable rehips.

Sorry I didn't mention before, my bad.

[fixer]

Don't worry, we'll look into this one and fix for sure.

[fixer]

Looks like for some unknown reason these processes don't like threads that start in them with start address pointing to LoadLibraryA or LoadLibraryW. This check takes place in ShellExt.dll resulting in ExitProcess with exit code 0. Maybe they try to protect their processes from DLL injection this way, but there are tons of other ways to inject a DLL and they don't cover them. So I'm not sure why they need it but it results in their processes just exiting.
I think the best way to solve this is to contact their support. If they really need this check, we'd have to make a workaround, I guess.

[Mr.X]

Saw once some months ago, when a user asked something I can't recall now, and they (Tony) said they really needed to do that check. So if you could make a workaround I'll be more than grateful. And if you can get me a test build please.

[fixer]

OK, if they need this check so deliberately, then workaround it is.
BTW, do you remember the topic? Maybe they stated the reason why they need it?