Windows 10: File System Filter 'wcifs' EVENT ID 4

So maybe I will not be the guinnee pig this time... *Tongue

 

Since this issue with restore points came to light I, and I'm sure others, have been concerned that the reliability of VSS might be comprised as well. This would call into question the reliability of backup software that uses VSS, such as Macrium to create images from within a running session of Windows. I decided to no longer do that and instead use the Macrium rescue USB stick to make full and differential backups until this issue is resolved by MS. Better to be safe than sorry. However, in an effort to resolve the question of VSS still functioning, I've decided that tomorrow morning I'll test one of my PC by using Macrium to run a full image backup from within Windows and then restore it. I'll post the results by mid-morning. I suspect that VSS will continue to function in spite of the restore point issue.

UPDATE 3/1/2017: Macrium was able to create images of the system (backups: fill, differential, and incremental) from within Windows with no problems. As another member pointed out, Macrium will warn you of any VSS issues before it actually begins writing the backups. FYI, Macrium uses VSS to create a "snapshot" of the volumes that it uses to select the files for backup.

 

Update on the (event id 4 'wcifs')

Not sure what/how, but on my laptop I started getting that error again when creating restore points. I looked at the fltmc instances and wcifs was attached to c:: ... So, it appears that auto starting wcifs and the loading of the wcifs filter is not an issue, it's when it gets attached to c: event id 4 'wcifs' shows up. I'm not sure but, I think when it attaches to c: is when it creates the 'wcifs.md' file in the 'c:\system volume infomation' foler. Still haven't found any info that file ???

I did 'fltmc detach wcifs c:' and I deleted the 'wcifs.md' from the 'c:\system volume information' (NOT sure I really need to delete it) and the error when away again.

Note: After did the above, on one of my restore tries I got the error about Anti Virus keeping restore from completing 'An unspecified error occurred during System Restore: (WindowsWcifs). Additional information: 0x80070005'. So it would seem that system restore and wcifs are related. I just don't know enough about it to work out the details.

Note: I was able to disable AVG and Malware Bytes and the restore completed successfully. See my last post post in ''AppxStaging %ProgramFiles%\WindowsApp 0x80070091 on getting to this point .... lol

 

Yet another data point, I guess, and it sounds like slightly different behavior. Starting Feb 22, I get the wcifs event id 4 / status 0xC000000D entry as soon as my laptop (Dell XPS13) goes into sleep mode, then within about 30 seconds my Intel igfx video driver immediately begins failing over and over every four seconds ("stopped responding and has successfully recovered") and nothing wakes it up again, I have to do a hard shutdown and reboot.

Since I can't see the screen at that point, I can't run fltmc, but after reboot it does show wcifs attached to C:

 

Sleeping is most probably also connected to VSS. :-/

 

SoFine409 ... I'm NOT recommending what I did as fix.

The DOMAIN\USERS with the Condition Exists Win://SYSAPPID is suppose to be there. If your going to start messing with permissions on the WindowsApps folder and sub folders, I STRONGLY suggest you get real familiar with ICACLS first. Back the current permissions to a file so can restore them in case you break something (which is very likely when screwing with permissions)

With that said, you have to take ownership of the folder "C\rograms Files\WindowsApps"

 

Thanks Eagle51. I wrote down the steps needed to rename the WindowsApp folder so I can try it on an old laptop that I keep for testing. I'll try it just for fun since I have saved images that I can use to restore it afterwards. I was just messaging with EdTittle and he recommends we use Feedback Hub to ping MS about this. The more heat they get the more likely we'll see a fix. BTW great detective work you and the other members have done. Are you an IT pro?
Bob

 

It dawned on me this morning, that maybe 'wcifs' is working like it's suppose to. When system restore fails, the 'wcifs' filter creates the 'wcifs.md' file in the 'c:\system volume information' folder and when system restore is successful it either deletes it or changes it's content. Once it's created in a failed state (either not deleted or contents changes) that's why we see the error on a reboot.

Since the contents of the 'wcifs.md' file is not really readable it's hard to tell if it changes (other than by size maybe) and since I just deleted the damn thing in my testing, I can't just put it back to verify.

Now that I got system restore working, need figure out how to make it fail / complete and try an verify .... lol

 

It should eventually fail as soon as the Get Office app updates on your PC. Or you could use Macrium and make an image of your OS as it is now and then do a clean install? The clean install would then likely update all the apps and break the restore function again.

 

SoFine409 ... probably, but I ain't going down that road again. Nope, not an IT Pro.

Note: Probably not a valid test.

I found a 'wcifs.md' file dated 2/20/2017 (1k), with what appears to be one ascii character/symbol in it [] . I think this is the original file, when I first noticed my restore issue, but can't be sure.

Put it in 'c:\system volume information'
Created a restore point and got the event id 4 filter manager warning.
Rebooted and got the event id 4 filter manager warning.

File System Filter 'wcifs' (Version 10.0, ‎2016‎-‎09‎-‎15T11:42:03.000000000Z) failed to attach to volume '\Device\HarddiskVolumeShadowCopy4'. The filter returned a non-standard final status of 0xC000000D. This filter and/or its supporting applications should handle this condition. If this condition persists, contact the vendor.

Then did a system restore on the restore point I just created and it completely successfully. That 'wcifys.md' file didn't get deleted or changed and fltmc instances shows wcifs is attached to c: Not sure this really sheds any light on the issue ... lol

 

So the the wcifys.md file serves as a marker for the message displayed on boot but the contents of the WindowsApps folder determines the success of the restore. The bad update of the Get Office app poisoned the WibdowsApp folder and until that is removed the restore will never be successful. Right? So by that logic then the contents of the wcifys.md file should be cleared by either renaming the WindowsApp folder or deleting the offending subfolder(s). Correct? But that doesn't happen, right? So maybe sonething else is in play?

 

SoFine409 ... I'm not really sure how all this ties together and I'm guessing there is something else in play that I/we don't know about.

wcifs.md -Does appear to be some kind of marker, but if/how wcifs interacts windows apps, I don't know. From what I've seen just renaming 'WindowsApps' folder and/or deleting (in this case) the 'Microsoft.MicrosoftOfficeHub_17.7909.7600.0_x64__8wekyb3d8bbwe' folder does NOT change wcifs.md file.

Get Office App - The update sure seems to have messed something up in regards to system restore. That's just the only app/folder I found on my system that fixed the restore issue. You would assume a M$ fix for the app would fix whatever the real issue is. Since it doesn't appear to affect every single user, your guess is as good as mine on if/when that might be. As far as just deleting the 'Microsoft.MicrosoftOfficeHub_17.7909.7600.0_x64__8wekyb3d8bbwe' folder .. that was just me being aggressive in my trouble shooting. It's possible leaving the app / folder alone and removing the DOMAIN\USER with the Exits Win://SYSAPPID would have achieved the same results. It could have also been another account permission issue that is causing the issue.

Trouble shooting these issues really should be done on a clean install and by someone more knowledgeable than me *Smile

 

I just tried renaming the WindowsApps folder and it didn't help. A also deleted the 'Microsoft.MicrosoftOfficeHub_17.7909.7600.0_x64__8wekyb3d8bbwe' folder but that didn't help either. I decided it was too much trouble to fiddle with the SDOMAIN\USER with the Exits Win://SYSAPPID. So it looks like the problem has different manifestations on different PCs. Either way I'm fed up with wasting any more of my time of this.

Be sure to use the Feedback Hub app to add your voice to the growing number of users who are complaining about this problem so maybe we can get it fixed in the next cumulative update.

Been good collaborating with you on this.
Bob

 

The only light it sheds on the problem for sure is that MS created a really big mess this time...