Ntfs (Ntfs) error event 138 in System event log

I've got like a two-months old Windows 8.1 system, and I've been trying to keep an eye on the event logs, to see if there's any error events I need to try to get fixed. Today I spotted the first one that really concerns me.

In the System events log, there's an Error type event with id number 138 from source "Ntfs (Ntfs)". Unfortunately my Windows is not English language, so I'm not really sure about what the error message would exactly be in English, but I'd translate it something like this from the original Finnish: "Events resource manager encountered a serious error in target C:\. It was shut down. The data contains the error code." I googled around, and I think I found the English version of that event, or at least something that sounds suspiciously the same, and it is this: "The transaction resource manager at C:\ encountered a fatal error and was shut down. The data contains the error code". Immediately after this error event there's a warning event 134 from the same source of "Ntfs (Ntfs)", and that event probably says this: "The transaction resource manager on volume C:\ encountered an error during recovery. The resource manager will continue recovery." These events appear to have happened during one of those many times the system is idle for a few minutes and starts doing some "maintenance" on its own in the background. There's only one (each) of these error/warnings in the log so far. I checked with a filter and there haven't been other errors like these ever on this system.

My question: What is this error event, and should I be concerned it means my hard drive has decided to start falling apart? It's a new drive (WD Black) and I haven't spotted any other signs of failure (yet)... If I open the C drive's properties in Explorer and use the error-checking tool thing, it runs quickly and says there are no errors on the drive. I'd appreciate any help. Hardware problems are scary. Dealing with software I can (mostly) manage, but when things physically break it's a little much for me... :/

Update:

What better way to spend my time than fixing unwanted computer trouble, no?

I downloaded Western Digital's Data Lifeguard Diagnostic for Windows and ran a Quick Test on the drive in question, it passed just fine. I'll try running an extended test later when I have more time.

Meanwhile, I also ran sfc /scannow, which I've done before on this system without issues, but what do you know, this time it came back with "Windows Resource Protection found corrupt files but was unable to fix some of them". I love how these problems can just come out of nowhere. But I like it even better that if I hadn't peeked around in the event log, I wouldn't know anything about this. Windows reminds me every day with a nice popup if I haven't yet downloaded the latest Windows Defender definitions from Windows Update, but when something like this happens, I have to go digging through event logs and command prompts to find out there's a problem. Augh.

So, I of course checked the CBS.log file that the sfc command's result referenced. And of course, it's enormous, with like a million lines of text. It'll take me a good while to make any sense of it, but even a quick glance reveals a lot of stuff like this:

2015-08-24 22:43:54, Info CSI 000000f3 [DIRSD OWNER WARNING] Directory [ml:520{260},l:92{46}]"\??\C:\Windows\Help\Windows\ContentStore\en-US" is not owned but specifies SDDL in component Microsoft-Windows-Assistance-CollectionFiles-Help.Resources, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture = [l:10{5}]"en-US", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral

2015-08-24 22:43:54, Info CSI 000000f4 Ignoring duplicate ownership for directory [l:46{23}]"\??\C:\Windows\SchCache" in component Microsoft-Windows-Active-Directory-Services-Interface-LDAP-Provider, Version = 6.3.9600.17415, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral

Click to expand...

Do I understand any of that? Of course not.
Then, this stuff caught my eye near the end of the enormous log:

2015-08-24 22:50:24, Info CSI 00000850 Hashes for file member \SystemRoot\WinSxS\amd64_prncacla.inf_31bf3856ad364e35_6.3.9600.17415_none_95dd5540d57f8c01\Amd64\CNBJ2530.DPB do not match actual file [l:36{18}]"Amd64\CNBJ2530.DPB" :
Found: {l:32 b:hb1Oxi3eMKqKoZDYay9Wz8NCYaEcFHDn4YNYmhTip10=} Expected: {l:32 b:n520k714Uu3utHa5JGQ6HQYbZphKhlMWq5pEmfnCDuw=}

2015-08-24 22:50:24, Info CSI 00000851 [SR] Cannot repair member file [l:36{18}]"Amd64\CNBJ2530.DPB" of prncacla.inf, Version = 6.3.9600.17415, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]"driverUpdate", TypeName neutral, PublicKey neutral in the store, hash mismatch

2015-08-24 22:50:24, Info CSI 00000852 Hashes for file member \SystemRoot\WinSxS\amd64_prncacla.inf_31bf3856ad364e35_6.3.9600.17415_none_95dd5540d57f8c01\Amd64\CNBJ2530.DPB do not match actual file [l:36{18}]"Amd64\CNBJ2530.DPB" :
Found: {l:32 b:hb1Oxi3eMKqKoZDYay9Wz8NCYaEcFHDn4YNYmhTip10=} Expected: {l:32 b:n520k714Uu3utHa5JGQ6HQYbZphKhlMWq5pEmfnCDuw=}

2015-08-24 22:50:24, Info CSI 00000853 [SR] Cannot repair member file [l:36{18}]"Amd64\CNBJ2530.DPB" of prncacla.inf, Version = 6.3.9600.17415, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]"driverUpdate", TypeName neutral, PublicKey neutral in the store, hash mismatch

Click to expand...

And now, I google more in hopes of understanding any of this. Computers are so fun and useful when they work as they're supposed to, but when they don't...

Personally I wouldnt let any of that bother me until you start seeing actual issues. Issues with corrupted files, programs not opening or running like they should, random crashes, etc. SFC /SCANNOW has been known to flag perfectly good files as corrupt. For what reason I dont know. Just leave it alone for now or you will just end up driving yourself nuts trying to fix something that probably isnt broken.

Thanks! I'm thinking you might be right. The system feels pretty stable, doesn't freeze or blue screen or slow weirdly or, well, anything. It seems to work fine. Just as long as I don't look in the event log and spook myself with the error events. Maybe reading event logs just gets me paranoid

I also managed to solve that sfc issue. (I think.) I had to do a Dism /Online /Cleanup-Image /RestoreHealth command, reboot, and after that running sfc again comes clean with no integrity violations. So if anyone else has that problem, trying the Dism command may be helpful. I also had time to run a chkdsk C: /R and that completed in about an hour. It makes an event log entry of its own with the results, and those are pretty difficult to figure out, but at least there's this line "0 KB in bad sectors." that I guess means chkdsk found no physical problems with the disk.

That pretty much leaves me back where I started, just wondering what that Ntfs error event 138 and warning event 134 was about. On one hand, I'd think that an error like that would be important, and like a bit of googling reveals might indicate a hard drive problem, but on the other hand, it would make sense that if such events were a sure indicator of hardware problems, Microsoft would have made Windows throw those errors right in your face so you can't miss them...