excessive writing on system32\Logfiles\WMI\RtBackup\EtwRTNT Kernel Logger.etl can I stop it?

Hi Stapp , no but i can try it! Good idea

 

I'm confused is this problem singling out mantra or is this widely reported? And nobodies certain what this is or what's causing it?

Would some kind some soul explain this to this 2 year old. Thanks

 

hi
may i ask which tool is more reliable to monitor and know how much does windows write on my disk?
i have used process hacker (older ) after 30minutes idles and i got this result

https://i.imgur.com/5OHNk2t.png
windows version screenshot
https://i.imgur.com/hm9pz5c.png
thanks

 

You can use Process Monitor's 'filter' feature to monitor only that file -

And click on OK. Now Process Monitor displays info that pertains only to that file.

I've tried to reproduce this issue in every imaginable way but no luck.

 

What I believe is going on is a NT kernel trace session as described here: https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/nt-kernel-logger-trace-session is being initiated at boot time and is constantly running.

The key to stopping the activity is to find out what is initiating it. Besides driver debugging when the feature was left enabled by mistake, it could also be app software related.

Also since this trace logging appears to be starting at boot time, I don't know if Process Monitor will be helpful in finding the source if PM is started after boot time. It will have to be configured to startup up and log activity at boot time I believe.

 

Process Monitor will generally show nothing, without installing the SDK and configuring debugging symbols we will just see kernel writing to the file.

Sure. I still stand by my comment that this is 3rd party related.

[EDIT] NT Kernel Logger should be running in a circular fixed size buffer, so new enties replace old in memory. It should only flush that buffer to the disk (log file) when explicitly told to do so, so an external process is calling for kernel to flush it's ram contents to a file. That's my theory/guess.

 

This might be a way to do so without installing SDK. Hopefully it still works on Win 10:

Resolve Symbols in Process Explorer-Monitor Without Installing the Debugging Tools
https://windowsexplored.com/2012/01...nitor-without-installing-the-debugging-tools/

 

I have seen a similar article, but it won't help. You will only see the internal functions used by ntoskrnl to write the log (instead of memory addresses you see without the symbols) but you can't see functions that are called against the kernel externally.
In my understanding, StartTrace is called and kernel logger just does it's job according to config, but what is calling the function is anybody's guess.

 

hi
i start to be really very annoying , i have done every advise
but may i ask you a question ?
is there a tool to monitor the I/O of my C: ?
is process hacker reliable ?

thanks

 

hi
yes it did , i create a local new user no luck
but i doubt about the 2 tools i have used ,FileActivityWatch & AppReadWriteCounter
what do you use to monitor the I/O of a drive or entire system?
thanks

 

From your post #28 I see in the first screenshot that everything is fine and no excessive writing is going on.

Post the screenshot.

[EDIT] Here's mine (I left it running for a couple of minutes), for comparison

 

I've been playing around with this thing a bit, the NT Kernel Logger is running when you use FileActivityWatch and it is capturing kernel events (when there are any), just as it should. (there are none in my above screenshot, and the logger is idle) But it is writing to a circular file and it stops immediately when I exit FileActivityWatch - or when the kernel event stops.

My conclusion - mantra got it all wrong, this is not an issue. The logger is writing to a circular file when there are kernel events running, on idle system it does not run. And it does not accumulate anything to the disk, as mantra's screenshot from post #28 shows.

mantra, take a look at "Event Trace Sessions", you have "NT Kernel Logger" there, this one corresponds to Circular Kernel Event Logger** startup item. And monitor it's behavior when you start/stop FileActivityWatch.
I would also like someone to additionaly confirm this behavior of NT Kernal Logger.

[EDIT] ** Circular Kernel Context Logger, my bad

 

I believe I can also explain a slew of leftover Event Log warnings mantra posted earlier (at least in my case I can).
When you run the app (I used my backup app, Drive Snapshot, for test) the logging begins, but when you exit the app the logging continues. The logger recognizes that it is still needed by FileActivityWatch but it can't write to the log anymore (I get ACCESS_DENIED in Process Monitor logs when I monitor the file) since you closed the original app (no real-time consumers) and FileActivityWatch does not run with SYSTEM privileges (which are need for the Backup folder) and the logger fires warnings. So they can be ignored as well as they are also the product of a 3rd party and this can't be fixed. FileActivityMonitor** basically logs it's own failed attempts to write to the log.

[EDIT] (again) FileActivityWatch

To add, I am not absolutely certain that I got all the workings here right, but one thing is for sure - this is by design and everything is OK.

 

Hi Sir @Seer

amazing research ! you know i was thinking to move to sierra or high sierra

but

but one think , if I run (i have always run as administrator) FileActivityWatch the read bytes and write bytes are very high ,and they increase very fast , and when i close it , the writing on my system continues , i have checked with process hacker the screenshot at #38

in the #38 screenshot i have reboot and i have not run FileActivityWatch .
I guess I will wipe it from my computer ,i unisntall almost everything ,drivers for first , create a new account , all for this little program
but again i appreciate a lot , again great analysis

 

mantra,
I am not quite correct about the details (I somehow never am) but the essence is true.
The screenshot in #38 shows FileActivityWatch as it is started while I'm watching a movie and browsing (as always). As soon as I start any app, the NT Kernel Logger starts and logging begins. But when I exit FileActivityWatch the logger stops immediately. Try to reproduce that.
You need to monitor the NT Kernel logger (in 'Sessioni di traccia eventi') but you have to constantly refresh (F5) the MMC console as it's just that bad.
You don't have to ditch anything, this is just how these low level monitoring apps work. There is just a need to understand their workings.

 

What do you exactly mean by this - what did you check with Process Hacker?
A live system will (globally) always write something to the disk.
(I never used it, but is Process Hacker an abandonware now?)

[EDIT] Alright, I have just checked this with Process Hacker. While running FileActivityWatch, and starting any other app, logging begins and Process Hacker registers massive I/O to the log file.
When I exit FileActivityWatch, the monitored log file immediately disappears from the Process Hacker list of monitored files.
All is fine.

 

@Seer
hi Seer
yes , i have performed some tests (i have deleted many times the logs files via cmd as administrator

Code:

for /F "tokens=*" %1 in ('wevtutil.exe el') DO wevtutil.exe cl "%1"

and all your analysis are right
i spend almost a day , well yes i still use process hacker , may i know what program do you use? Process Explorer?
thanks really really appricate your help

 

Just to add - while this was a false alarm, I can totally understand your concern. This kernel logging thing can be scary when you don't know what you're looking at (especially since it utilizes a single core at almost 100%) and I admit that it scared me for a couple of moments until I figured out what was going on. (I still don't understand fully the relations between FAW and kernel logger but I've had enough testing for now) You don't tinker with these loggers every day and most users are not even aware of them.

Yes, you can clear the logs of kernel loggers warnings. Again, they can be safely ignored as they are the product of using FileActivityWatch.

I actually keep the things simple and use Task Manager. I only use these tools in cases like this one.

And to repeat, there is no need to uninstall anything or create another user or whatever. Next time you use FAW to monitor file activity, simply ignore kernel logger - it just follows it's default configuration and does it's job.

You are most welcome and thank you for this interesting and challenging thread.

Cheers.