The unofficial Shadow Defender Support Thread.

Version .665 on two Win 10 machines (creators update). This is the best SD version ever in my experience, It used to take quite a bit of time to reboot in normal mode, with the latest it takes almost as long as a normal restart.

Fast startup on some systems does not work well with SD.

 

One day, I was using version 578 in shadow mode. I created more than 3000 files and about 1GB in total, suddenly the SD tray icon became yellow from blue and after a while, windows crashed and rebooted again and all the files I created were gone.

 

Heard back from support. I though increasing the other amount would be better but they had me decrease it from the 1000 MB to 1 MB and that worked. Default is 200 MB. So still wondering it works for everybody else and not me until I made the adjustment. And it happened after the last update.
Here is what support suggested.

Z: is the system hidden drive, SD need to mount it to protect it. To avoid this message please goto "Administration > Notify me with low free space on the protected volume > More Details" and set Others space to 1MB.

 

It still takes noticeable more time to reboot in normal mode, in my case, with Windows 1703 and SD 665.

 

I´d create the files in a non-shadowed data partition.

 

I was mirroring some folders for test and actually I did it again in non-shadowed data partition. I think it is better to report it here to get the author informed and to improve it. I saw a similar post long time ago in this forum but not remember exactly where it is.

 

I agree Peter. I've not had a problem like that myself though. I'm just wondering if kakaka has enough room on his drive to perform the operation? There is the old internet adage when creating large essays or 'masterpieces' to avoid tears in a crashy 'dows environment 'save often'. That way, if 'dows crashes you haven't lost everything. Similarly in Shadow Mode right click and commit as you build. If you are working on a file and adding to it commit again reguarly (once the file is initially saved) when you've made any changes. I hope that this makes sense.

 

Thanks for testing that. Never made enough new files to that extent to have that issue but a recent ransomware test did dump quite a collection in folders and desktop like it was trying to flood. LoL

Always good to know if, and, or where this puppy has a particular limit.

I also use 578 on the ole trusty Windows 8.1 and don't believe in upgrading unless absolutely necessary. If it's not broke it don't need fixin' motto.

 

For sure, I had enough room for that operation (I have more than 20GB left and those file only took about 1GB). I guess it was about the number of the files involved . It was weird I actually saw the tray icon changed its color and then crashed.

 

Nice to see that the development of Shadow Defender is continuing, so I'm back with some news about the mythical corruption issue

For new users, check it out here:

I have since zero-filled my HDDs, then run extended self-tests on then, after that memtest86, and finally rebuilt my System. After a while, I started testing Shadow Defender again, this time in a 32bit Windows 7 SP1 VMWare environment, and I cound NOT reproduce the corruption, at least not immediately.

I have used a second, small 4GB virtual Hard Disk, putting it in Shadow Mode and trying to reproduce corruption, to no avail. After a while, I tried the same on the system disk, and the corruption was back almost instantly. I then created another, 16GB virtual disk, filled it with random files until the number of file approximately matched my system drive, and could easily reproduce corruption on it, as well.

So now I believe that it must be some kind of buffer-overflow tied to the state of MFT, meaning that the number of metadata entries must be above a certain threshold for bad files to occur.

Anyway, I've devised a relatively hassle-free way for users to check for this phenomenon on their systems, in an unattended way:

Requirements:
1. Windows 7 SP1 32bit installed on a 16GB Virtual Disk in VMWare (or your preferred virtualization environment, though I've only tested it in VMWare)
2. Shadow Defender (that's pretty obvious)
3. Java Runtime Environment (Java is not really needed, I just found that the Java folder with its mix of large and small files is ideal for finding corruption, prevents stress on the HDD and my script relies on a Java folder being present in "Program Files")
4. HashDeep (It's IMHO the best open source commandline hasher, you can get it here: https://github.com/jessek/hashdeep/releases.)

Next, do the following:

1. Create a "temp" folder in the root of C:\

Be advised that all folders whose name starts with "Copy" inside this temp folder (the script will be run from it) will be deleted!

2. Put "hashdeep.exe" from the downloaded archive in C:Windows, or any folder listed in the PATH environment variable)

3. Install Java Runtime Environment (Using the default installation Folder, "C:\Program Files\Java")

4. Open a command prompt in C:\Program Files\Java (this is important, because of the file paths in the hash file)

5. Run this command:

Code:

hashdeep -j0 -e -rl * >"C:\temp\audit.txt"

That's our audit file for hashdeep.

6. Create a .bat (maybe name it shadowtester.bat ?) file in C:\temp and paste the following in it:

Code:

@echo off
setlocal enabledelayedexpansion
:COUNTER
FOR /L %%i in (0,1,30) DO @CALL :COPY %%i
echo Done.
GOTO CHECK

:COPY
xcopy "C:\Program Files\Java" "Copy%1" /S /E /V /I /F /Y
GOTO:EOF

:CHECK

FOR /D %%G IN ("Copy*") DO (
PUSHD %%~nxG
hashdeep -j0 -e -v -v -v -a -k "C:\temp\audit.txt" -rl *
  if !ERRORLEVEL! EQU 1 (
  ECHO Corruption found
  PAUSE
  EXIT /b !errorlevel!
) ELSE ( POPD )
)

FOR /D %%G IN ("Copy*") DO RMDIR "%%G" /S /Q

GOTO COUNTER

This quick&dirty batchfile will infinitely loop, creating 30 copies of "C:\Program Files\Java" in C:\temp, check their integrity, delete them, and start again.

Finally, install Shadow Defender, enable Shadow Mode and let the script run, the longer, the more certain you can be corruption does not happen on your system. If it stops with a "Corruption found" message, you are affected (and probably should repeat the procedure on your real system)

On my system, corrution is found relatively quickly, quite often within a couple of minutes.

You may need to increase the number of copies by changing the last counter in the FOR /L loop on the 4th line on the script to something larger than 30, around 50 copies can fit on my Virtual System, but it shouldn't be necessary

 

@sdmod what is the max file/s size that you should commit without any problems or it taking too long?

 

Here is my reply from Tony,

Patrick

............................................................................

Hi Patrick, Thanks for your help and feedback. I will work on it. Best regards, Tony

On 05/10/2017 04:00, Admin wrote: Hi Tony, On Wilders forum is someone who has identified a problem concerning a corruption issue. best wishes Patrick https://www.wilderssecurity.com/thr...hadow-defender-support-thread.293075/page-202 below post #5037 ' Nice to see that the development of Shadow Defender is continuing, so I'm back with some news about the mythical corruption issue For new users, check it out here: I have since zero-filled my HDDs, then run extended self-tests on then, after that memtest86, and finally rebuilt my System. After a while, I started testing Shadow Defender again, this time in a 32bit Windows 7 SP1 VMWare environment, and I cound NOT reproduce the corruption, at least not immediately. I have used a second, small 4GB virtual Hard Disk, putting it in Shadow Mode and trying to reproduce corruption, to no avail. After a while, I tried the same on the system disk, and the corruption was back almost instantly. I then created another, 16GB virtual disk, filled it with random files until the number of file approximately matched my system drive, and could easily reproduce corruption on it, as well. So now I believe that it must be some kind of buffer-overflow tied to the state of MFT, meaning that the number of metadata entries must be above a certain threshold for bad files to occur. Anyway, I've devised a relatively hassle-free way for users to check for this phenomenon on their systems, in an unattended way: Requirements: 1. Windows 7 SP1 32bit installed on a 16GB Virtual Disk in VMWare (or your preferred virtualization environment, though I've only tested it in VMWare) 2. Shadow Defender (that's pretty obvious) 3. Java Runtime Environment (Java is not really needed, I just found that the Java folder with its mix of large and small files is ideal for finding corruption, prevents stress on the HDD and my script relies on a Java folder being present in "Program Files") 4. HashDeep (It's IMHO the best open source commandline hasher, you can get it here: https://github.com/jessek/hashdeep/releases.) Next, do the following: 1. Create a "temp" folder in the root of C:\ Be advised that all folders whose name starts with "Copy" inside this temp folder (the script will be run from it) will be deleted! 2. Put "hashdeep.exe" from the downloaded archive in C:Windows, or any folder listed in the PATH environment variable) 3. Install Java Runtime Environment (Using the default installation Folder, "C:\Program Files\Java") 4. Open a command prompt in C:\Program Files\Java (this is important, because of the file paths in the hash file) 5. Run this command: Code: hashdeep -j0 -e -rl * >"C:\temp\audit.txt" That's our audit file for hashdeep. 6. Create a .bat (maybe name it shadowtester.bat ?) file in C:\temp and paste the following in it: Code: @Echo off setlocal enabledelayedexpansion :COUNTER FOR /L %%i in (0,1,30) DO @CALL :COPY %%i echo Done. GOTO CHECK :COPY xcopy "C:\Program Files\Java" "Copy%1" /S /E /V /I /F /Y GOTO:EOF :CHECK FOR /D %%G IN ("Copy*") DO ( PUSHD %%~nxG hashdeep -j0 -e -v -v -v -a -k "C:\temp\audit.txt" -rl * if !ERRORLEVEL! EQU 1 ( ECHO Corruption found PAUSE EXIT /b !errorlevel! ) ELSE ( POPD ) ) FOR /D %%G IN ("Copy*") DO RMDIR "%%G" /S /Q GOTO COUNTER This quick&dirty batchfile will infinitely loop, creating 30 copies of "C:\Program Files\Java" in C:\temp, check their integrity, delete them, and start again. Finally, install Shadow Defender, enable Shadow Mode and let the script run, the longer, the more certain you can be corruption does not happen on your system. If it stops with a "Corruption found" message, you are affected (and probably should repeat the procedure on your real system) On my system, corrution is found relatively quickly, quite often within a couple of minutes. You may need to increase the number of copies by changing the last counter in the FOR /L loop on the 4th line on the script to something larger than 30, around 50 copies can fit on my Virtual System, but it shouldn't be necessary Last edited: May 8, 2017 at 8:19 AM' ............................................................. ................................................................ Also a Wilders member asked this question post #5038 ' @sdmod what is the max file/s size that you should commit without any problems or it taking too long?' Overkill, May 9, 2017 at 11:19 AM #5038 --

 

Hi, sorry for i am to ask something that is a bit too much...is our latest version capable of surviving the so called Wannacry ransomware that is currently infesting the internet? I really want to brag about it and tell my friends to use SD as additional layer of protection against these nasty threats .As i've read somewhere our SD survived Petya. Thanks.

 

There's a new version available at shadow defender servers, 1.4.0.668: http://www.shadowdefender.com/download/SD1.4.0.668_Setup.exe

No changelog available as of now and download page (http://www.shadowdefender.com/download.html) still reports version 1.4.0.665.

 

Same on a Windows 10 I been testing lately.

But I have a question.

Shadow Defender uses a virtual piece of the disk of course and then coming out of Shadow Mode via reboot normally or hard reset dumps or deletes it.

Is that same piece of the disk reused over and over again on every new session?

 

I don't know for certain, I guess it depends on the size of the real system and the degree of fragmentation. I always use "RAM used as a Write Cache: 4000 MB" therefore, as I understand it, the whole virtual session is retained in memory (unless exceeded) and nothing is written to disk.

 

That's a much better choice and one I would prefer.

Is there a decent guide handy or a link to catch up on this with? Thanks Osaban.

Since junkware testing is a favorite it would do much better I think to be able to bounce that really bad stuff around in memory like that then scrap it on disk.

 

One can assign arbitrarily the amount of RAM deemed suitable according to the total amount of RAM available.

As an example my notebook has 8 GB of RAM, and when I use SD, I set the maximum RAM available for the Write Cache to 4 GB, but it could be 1 GB or 2GB. Obviously for a machine with only 1 GB of total RAM, it is not recommended to assign anything to SD as the OS would slow down as a result.

Once RAM has been assigned it means that the whole shadow mode session will be retained in RAM, and provided the virtual volume doesn't exceed the maximum amount assigned to the Write Cache, rebooting your computer out of shadow mode will effectively ERASE and not DELETE everything that took place in shadow mode. Excellent for privacy.
https://www.wilderssecurity.com/threads/what-exactly-does-shadow-defender-do.355575/ see from post 15

 

Once again thanks for the pointers with this.

I assigned 2Gb of 4 so will give that a try the next time and see how it holds up or try to measure how long it takes before getting near the RAM limit.

Nice feature I really haven't taken much interest in until now.

 

Easter you are welcome. A write cache of 4GB usually is enough for a time window of 2-3 hours of normal shadow use. It also depends on the the activities, downloads, transfer of files, etc...

 

This version is often connected with words crak, pirated, keygen and often listed on Russian pages...so I don't think is wise to download and run such installer.

 

Can't find any sense on this, cause the installer is signed.