Jump to content

Heavy writing onto SSD until storage runs out


Kuroi

Recommended Posts

Hello everyone, after a BSOD I can now write it all again, forgive me some sloppiness. I am currently using KIS 18.0.0.405 and have encountered a severe problem although I do not know if the behavior is not intended. I have not seen this before at least on my machine. As of yesterday, KIS has apparently crashed for the 2nd time without notice within around one month, which I only realized after I hovered the tray-icon which would then disappear upon which I restarted KIS. As usual I was concerned and began a full scan. I left the computer to do this and much later, as the scan was still running wanted to open some files and realized that my C Drive, a 500 GB 850 EVO showed me 5 GB of remaining space. As I was absolutely certain that I would’ve never filled up my SSD that much I tried to instantly investigate but upon refreshing, I also realized that I could literally watch my drive space disappearing into thin air at an alarming rate. Within less than 30 seconds I was down to less than 1 GB and thought of a virus, expecting a crash as I refreshed a last time around 200 MB left. At that point however my SSD space magically went back to my original ~65 GB of remaining space. The problem didn’t disappear as my SSD space was once more rapidly disappearing in front of my eyes, first checking my SSD health and an SSD tool I made sure that this wasn’t just some error, no something was indeed writing at an alarming rate onto my SSD. Using Process Explorer, Process Monitor and the Resource Monitor I figured out that apparently KIS was writing at insane rates to my SSD, all into C:\Windows\Temp as PR****.log. Stopping the full scan would instantly stop the writes, while starting it again would instantly resume the writes. KIS did not find anything under the quick scan and 70 % into the total scan - which is where I aborted - nothing either. MBAM has not come up with anything either. Computer stable - at least until I tried to recreate the issue - for 24 hours. After a lot of internet research I saw some other people had similar problems way back until 2008 and 2010. I eventually restarted the scan and then realized that the write-rates were normal while it was scanning my C Drive, but instantly went crazy once it hit one of my data-drives. Now my assumption at this point is that this is connected to how Kaspersky checks archives. I have a lot of packed files on my data-drives and – I have no idea – at this point guess that Kaspersky analyzes those by somehow unpacking them in a safe environment. On the one hand that wouldn’t be so bad, although my SSD program told me I was currently writing around 2.5 TB of data per day and a full scan of my system might easily take that long which absolutely cannot be healthy. Especially if KIS decides to crash a few more times on me, prompting me to do another full scan. On the other hand even if that is the case, none of my archives is bigger than ~5 GB and I could see no reason why Kaspersky would write that much data onto my SSD and keep it there until the system runs out of memory instead of deleting it again once an archive would be checked. At first I was still not convinced as my storage had magically reappeared as it hit zero, but just as I was still researching my computer had a BSOD for probably the first time in… years. I cannot say whether this BSOD is connected to Kaspersky writing to my drive at all at this point, but it seems too convenient to be a pure coincidence. Trying to turn off the options for checking archives and enabling additionally that KIS should not check archives bigger than 100 MB has proven futile at solving this problem. As I am not even certain whether this is the cause, how Kaspersky actually works in such situations or what I can do at this point apart from moving my TEMP-Folder to another drive – I decided to see if someone can help me at figuring this out. Also note that moving my TEMP-Folder to another drive would not really bother me but it still seems incredibly strange that KIS would write hundreds of GB to a drive and then keep them there until the drive runs out of space. Is that really intended behavior? Would upgrading KIS even solve this problem? Am I on the right track about the archives at all or is it wrong anyway? Thanks for any kind of help. System Info in short: Windows 10, KIS 18.0.0.405, Samsung 850 EVO 500 GB SSD, 4 Drives total (500 GB, 3 TB, 3 TB and 600 GB), 16 GB RAM The rest I assume would not matter. TL; DR: KIS writing insane amounts of data to SSD until SSD runs out of storage, then apparently resets (or crashes to BSOD) while running a full scan, possibly packed files causing the issue.
Link to comment
Share on other sites

Flood and Flood's wife
TL; DR: KIS writing insane amounts of data to C:\Windows\Temp as PR****.log SSD until SSD runs out of storage, then apparently resets (or crashes to BSOD) while running a full scan
Hello Kuroi, Welcome! Thank you for posting this important issue.:clap_tone3: I don't see any cluminess at all, you've covered everything comprehensively:thumbsup_tone3: It's a known issue, and, way more recent than 2008. "Known" as in, 2019. I'll pm you the details, including Klab's "advice", later tonight. Best regards:pray_tone3:.
Link to comment
Share on other sites

Hello FLOOD, Thank you! Not just for the welcome but also the quick response. I tried to cover everything but I mean it could've been worse as I felt tired and a little bit annoyed after having to rewrite several things again while also a bit worried as to what causes all of this. That its a known issue must be a good thing although this probably also means my rather extensive web research has failed to come up with an answer then. I usually try not to bother people if solutions can be found elsewhere but be assured that I did research thoroughly, but had a hard time to come up with anything. The reason why I speculated this to be an older cause is due to a few posts I found from way back then, on the old Kaspersky board: https://forum.kaspersky.com/index.php?app=forums&module=forums&controller=topic&id=113804&tab=comments#comment-953960 https://forum.kaspersky.com/index.php?app=forums&module=forums&controller=topic&id=63141&tab=comments#comment-576888 I just felt like adding this as it seems quite, quite similar although no solution was found, apparently, at least nothing that I could've used. Thank you again, I shall be waiting for your reply. Kind regards.
Link to comment
Share on other sites

Flood and Flood's wife
Not just for the welcome but also the quick response. I tried to cover everything but I mean it could've been worse as I felt tired and a little bit annoyed after having to rewrite several things again while also a bit worried as to what causes all of this.
Hello Kuroi, You've done good research, your approach has been very reasoned and thorough:thumbsup_tone3:. I understand "being worried", especially when disk spaces gets chewed up in front of our eyes. I also understand and appreciate you getting annoyed, I would (& have at times) too! Just a hint about "rewriting", I've trained myself to write everything in a text/notepad file, before I post, then, even if the network fails or the PC dies, I've still got all my work! You'll have the history before midnight.
  1. One question I meant to ask, why are you still on 18.0.0.405?
My very best regards
Link to comment
Share on other sites

Hello FLOOD, Ironically I did indeed write my message into an editing program before posting it, although it has no auto-save and I did not yet save, losing my progress pretty much. There is in fact no specific reason, other than that everything until this point has worked pretty much flawlessly until a single crash around a month ago and my license being nearly at the end but I have bought a new one around 2 weeks ago already for another 2 years and thats when I do usually upgrade my KIS. So I am running a 2 year upgrade cycle, usually skipping over one version and then installing the newest one after it's been out for some months. My first reaction was actually to update KIS to the 20.0.14 version instantly (normally this would've happened within the next 10 days per my cycle) and I had already downloaded this before the BSOD occured. Thats why the last part of my question was:
Would upgrading KIS even solve this problem? Am I on the right track about the archives at all or is it wrong anyway?
Normally I would've just updated and checked if there would have been an improvement, at the same time I decided to hold off until I had some clarification whether this was now Kaspersky or not. As I said, I ran a new scan to test this but did not expect the BSOD. At this point I thought it might be worth asking first before installing a new version, should this not be related, would it been known but not fixed in a new version, would someone here need me to replicate the issue in order to search for a solution, could this have been a virus after all as noone here might have heard of such an issue before (due to the writes my heartrate went quite up as I expected some Ransomware trying to encrypt files). That was my reasoning behind it. As I now also realize, I thought I had written it down but after the BSOD the message was lost so I did not write it again but thought it was still there: I intended to install a new version regardless as I hoped my only issue at the point of the crash and my start of the full scan was a crashing KIS (which would honestly be bad enough for an AV). A single time might be a fluke, but a second time sure is not in my books. So after I would have figured out - or not - what this problem is, I intended to install a newer version of KIS regardless. Kind regards.
Link to comment
Share on other sites

but after the BSOD the message was lost
Also and in addition to FLOOD , please check with BleuScreenView (Nirsoft) If you suspect that Kaspersky was causing a BSOD , then your only option is K-Lab Technical Support
Link to comment
Share on other sites

Flood and Flood's wife
After a BSOD I can now write it all again, forgive me some sloppiness. I am currently using KIS 18.0.0.405 and have encountered a severe problem although I do not know if the behavior is not intended. I have not seen this before at least on my machine. As of yesterday, KIS has apparently crashed for the 2nd time without notice within around one month, which I only realized after I hovered the tray-icon which would then disappear upon which I restarted KIS. As usual I was concerned and began a full scan. I left the computer to do this and much later, as the scan was still running wanted to open some files and realized that my C Drive, a 500 GB 850 EVO showed me 5 GB of remaining space. As I was absolutely certain that I would’ve never filled up my SSD that much I tried to instantly investigate but upon refreshing, I also realized that I could literally watch my drive space disappearing into thin air at an alarming rate. Within less than 30 seconds I was down to less than 1 GB and thought of a virus, expecting a crash as I refreshed a last time around 200 MB left. At that point however my SSD space magically went back to my original ~65 GB of remaining space. The problem didn’t disappear as my SSD space was once more rapidly disappearing in front of my eyes, first checking my SSD health and an SSD tool I made sure that this wasn’t just some error, no something was indeed writing at an alarming rate onto my SSD. Using Process Explorer, Process Monitor and the Resource Monitor I figured out that apparently KIS was writing at insane rates to my SSD, all into C:\Windows\Temp as PR****.log. Stopping the full scan would instantly stop the writes, while starting it again would instantly resume the writes. KIS did not find anything under the quick scan and 70 % into the total scan - which is where I aborted - nothing either. MBAM has not come up with anything either. Computer stable - at least until I tried to recreate the issue - for 24 hours. After a lot of internet research I saw some other people had similar problems way back until 2008 and 2010. I eventually restarted the scan and then realized that the write-rates were normal while it was scanning my C Drive, but instantly went crazy once it hit one of my data-drives. Now my assumption at this point is that this is connected to how Kaspersky checks archives. I have a lot of packed files on my data-drives and – I have no idea – at this point guess that Kaspersky analyzes those by somehow unpacking them in a safe environment. On the one hand that wouldn’t be so bad, although my SSD program told me I was currently writing around 2.5 TB of data per day and a full scan of my system might easily take that long which absolutely cannot be healthy. Especially if KIS decides to crash a few more times on me, prompting me to do another full scan. On the other hand even if that is the case, none of my archives is bigger than ~5 GB and I could see no reason why Kaspersky would write that much data onto my SSD and keep it there until the system runs out of memory instead of deleting it again once an archive would be checked. At first I was still not convinced as my storage had magically reappeared as it hit zero, but just as I was still researching my computer had a BSOD for probably the first time in… years. I cannot say whether this BSOD is connected to Kaspersky writing to my drive at all at this point, but it seems too convenient to be a pure coincidence. Trying to turn off the options for checking archives and enabling additionally that KIS should not check archives bigger than 100 MB has proven futile at solving this problem. As I am not even certain whether this is the cause, how Kaspersky actually works in such situations or what I can do at this point apart from moving my TEMP-Folder to another drive – I decided to see if someone can help me at figuring this out. Also note that moving my TEMP-Folder to another drive would not really bother me but it still seems incredibly strange that KIS would write hundreds of GB to a drive and then keep them there until the drive runs out of space. Is that really intended behavior? Would upgrading KIS even solve this problem? Am I on the right track about the archives at all or is it wrong anyway? Thanks for any kind of help. System Info in short: Windows 10, KIS 18.0.0.405, Samsung 850 EVO 500 GB SSD, 4 Drives total (500 GB, 3 TB, 3 TB and 600 GB), 16 GB RAM The rest I assume would not matter. TL; DR: KIS writing insane amounts of data to SSD until SSD runs out of storage, then apparently resets (or crashes to BSOD) while running a full scan, possibly packed files causing the issue.Hello FLOOD, Thank you! Not just for the welcome but also the quick response. I tried to cover everything but I mean it could've been worse as I felt tired and a little bit annoyed after having to rewrite several things again while also a bit worried as to what causes all of this. That its a known issue must be a good thing although this probably also means my rather extensive web research has failed to come up with an answer then. I usually try not to bother people if solutions can be found elsewhere but be assured that I did research thoroughly, but had a hard time to come up with anything. The reason why I speculated this to be an older cause is due to a few posts I found from way back then, on the old Kaspersky board: https://forum.kaspersky.com/index.php?app=forums&module=forums&controller=topic&id=113804&tab=comments#comment-953960 https://forum.kaspersky.com/index.php?app=forums&module=forums&controller=topic&id=63141&tab=comments#comment-576888 I just felt like adding this as it seems quite, quite similar although no solution was found, apparently, at least nothing that I could've used. Thank you again, I shall be waiting for your reply. Kind regards.Hello FLOOD, Ironically I did indeed write my message into an editing program before posting it, although it has no auto-save and I did not yet save, losing my progress pretty much. There is in fact no specific reason, other than that everything until this point has worked pretty much flawlessly until a single crash around a month ago and my license being nearly at the end but I have bought a new one around 2 weeks ago already for another 2 years and thats when I do usually upgrade my KIS. So I am running a 2 year upgrade cycle, usually skipping over one version and then installing the newest one after it's been out for some months. My first reaction was actually to update KIS to the 20.0.14 version instantly (normally this would've happened within the next 10 days per my cycle) and I had already downloaded this before the BSOD occured. That's why the last part of my question was:
Would upgrading KIS even solve this problem? Am I on the right track about the archives at all or is it wrong anyway?
Normally I would've just updated and checked if there would have been an improvement, at the same time I decided to hold off until I had some clarification whether this was now Kaspersky or not. As I said, I ran a new scan to test this but did not expect the BSOD. At this point I thought it might be worth asking first before installing a new version, should this not be related, would it been known but not fixed in a new version, would someone here need me to replicate the issue in order to search for a solution, could this have been a virus after all as no one here might have heard of such an issue before (due to the writes my heart rate went quite up as I expected some Ransomware trying to encrypt files). That was my reasoning behind it. As I now also realize, I thought I had written it down but after the BSOD the message was lost so I did not write it again but thought it was still there: I intended to install a new version regardless as I hoped my only issue at the point of the crash and my start of the full scan was a crashing KIS (which would honestly be bad enough for an AV). A single time might be a fluke, but a second time sure is not in my books. So after I would have figured out - or not - what this problem is, I intended to install a newer version of KIS regardless. Kind regards.
Hello Kuroi, I'll put what (imo) you need to prepare, at the top of my reply: (before) you contact the Lab, (imo), their first response will be to advise (you) to upgrade to 2020, and retest the issue. ---- If the issue repeats (with 2020), present everything (to the Lab) you've presented here: history, analysis, data collection and a very big dose of patience. --- If you choose to upgrade to 2020, please follow this process:
  1. Prepare computer - Before installation & Compatibility Library
  2. Check - KIS2020 Hardware & Software requirements
  3. Uninstall 2018 - save "LICENCE info" only.
  4. Reboot computer, using FULL shutdown, not "restart"
  5. Restart computer, login and download 2020.
  6. Install 2020.
  7. Reboot computer, using FULL shutdown. not "restart"
  8. Restart computer, login, make sure KIS2020 is active & synchronised with MyKaspersky portal.
  9. Run a manual database update - allow it to complete.
  10. Retest issue.
  11. If issue repeats, contact Lab: Diagnostics Library, including traces, dumps, GSI & Windows logs
--- The following is the track of how the Lab previously managed the issue (April 2019): 13-April, 11:55
  1. Kaspersky process/s are creating PR* files in C:\Windows\Temp that use 60, 70, 80gb (excessive) data in a matter of minutes. Why?
Attached TRACES.zip [PRx files].jpg ---------- 17-April, 15:00 Kaspersky Lab Support: Greetings! We appreciate you getting in touch. The “PR” files do not appear to be coming from Kaspersky. The screenshot indicates that the files are being scanned by Kaspersky. You may temporarily exit Kaspersky to see if the large temp files continue to be created. To do so, right-click on the Kaspersky green shield icon in System Tray (on the bottom right corner of your screen) and select “Exit”. ---- 17-April, 16:44
  1. Kindly explain how you've come to the conclusion" “PR” files do not appear to be coming from Kaspersky"?
---- 18-April, 11:00 Kaspersky Lab Support: Kaspersky programs do not generate log files with names beginning with “PR”. Are the Windows temp files still being created after exiting Kaspersky? ---- 18-April, 13:55
  1. No
---- 19-April, 09:35 Kaspersky Lab Support: We have forwarded the information you have provided to our escalation team to investigate. Please wait for our reply. ---- 20-April, 14:00 Kaspersky Lab Support: Our Escalation Team have confirmed that PR**.tmp files are being created during scanning procedure (either with on-demand scan task or with File-AV activity) when Kaspersky proceeds with unpacking compound files (archives, .iso images, outlook's .pst file and so on). Normally PR***.tmp file should be removed after scanning of the original file. If it's not, then it seems like there's some conflicting application which locks the .tmp file from being removed. Or if scanning procedure doesn't finish for some reason, the .tmp files will not be removed. Unfortunately, the trace logs doesn't provide much details. If the issue is still reproducible, collect another set of trace, and ProcMon logs. ---- 20-April, 15:00
  1. Done
TRACES-1.zip Procmon.zip. ---- 20-April, 16:55 Kaspersky Lab Support: We have forwarded the information you have provided to our escalation team to investigate. Please wait for our reply. ---- 22-April, 09:08 Kaspersky Lab Support: Unfortunately, the logs doesn't provide much details. If the issue is still reproducible, collect another set of trace, and ProcMon logs. ---- 22-April, 10:33
  1. Done
TRACES-2.zip Procmon-1.zip. ----- 22-April, 11:45 Kaspersky Lab Support: We have forwarded the information you have provided to our escalation team to investigate. Please wait for our reply. ---- 24-April, 14:01 Kaspersky Lab Support: Unfortunately, the logs doesn't provide much details. If the issue is still reproducible, collect another set of trace, and ProcMon logs. ---- 24-April 16:45
  1. Done
TRACES-3.zip Procmon-2.zip. ----- 25-April 09:10 Kaspersky Lab Support: We have forwarded the information you have provided to our escalation team to investigate. Please wait for our reply.. ---- 29-April 10:03 Kaspersky Lab Support: Unfortunately, the logs doesn't provide much details. If the issue is still reproducible, collect another set of trace, and ProcMon logs. Please keep us updated Kuroi Thank you and best regards
Link to comment
Share on other sites

smipx If you are talking about a BSOD caused by Kaspersky, your best option is K-Lab Technical Support. Encountering this kind of issue can be caused by different malfunctions that requires different advices.
Link to comment
Share on other sites

Hello everyone, I will still write a full reply although I think I’ve figured this out now and it is partly solved, although it might be problematic for other users under similar usage so should anyone else encounter this issue, this might be the answer. Berny I did of course try to figure out the reason for the blue screen on my own but the error code - to me - was one of those that could've been quite anything. It was rather the timing that made me suspicious, as I believe this computer has not suffered a bluescreen within the last 4 years. So during the testing of the issue, a blue screen was rather suspicious. I have installed BlueScreenView but this would not come up with anything, as there seem to be no logs in the folder specified by the program and I was unable to locate the minidumps elsewhere. Right after the crash I checked the EventLog and it came up with 0x00000101. FLOOD Thanks for the reply, I've done as you said and uninstalled/reinstalled the program as per instruction and deleted MBAM during the installation as Kaspersky was nagging me about it, just to be sure. The program seems a bit sluggish in speed compared to the older one but this might fix itself after it ran for some time (I hope). My SSD showed me 71.1 GB free after uninstalling KIS and installing the new version, leaving me with 6 GB more than before. Quick Scan came up with nothing, skipping another full scan and going straight for a custom scan of a data drive would again result in data being written to the SSD. KIS keeps creating small files that instantly disappear but also created another large file that reached 11.818.432 KB before I cancelled the scan. After ending the scan, this time KIS would instantly free up the space again, although I believe this to be due to the custom scan. You cannot resume a custom scan, so a full scan might keep the data in the TEMP folder until you fully reset it. As I now understand this is all actually intended behaviour. So just to confirm this, I instead checked my folder for some packed files and ran a scan of those (20.8 GB packed file, 25 GB unpacked) will indeed create a ~25 GB .tmp file by Kaspersky before proceeding to delete it. As the file would vanish once the scan is done I kept refreshing but the numbers check out. This means KIS will unpack the full archive every time to scan it. While I understand this, it is rather poorly implemented, considering that many people might actually run an SSD as System Drive which not only has limited writes but also often limited space. If you would have 50 GB as buffer you will inevitably run into problems trying to scan packed archives larger than this, which means KIS is probably not even able to scan those files as it might very well realize that the drive runs out of space, just delete the so-far unpacked archive and proceed to scan the next file. Considering KIS could first check whether it actually has enough space available to unpack such a file before starting to unpack GB of data onto a limited SSD seems logical to me. Not considering that people that have several data drives like me for storage or professional reasons might actually cause problems to their SSD eventually. While I am fully aware of modern SSD's durability, my SSD program told me that at current, KIS was writing around 1.5 TB of data per day. Considering that a full scan of several drives might easily result in a scan taking more than one day, a full scan should probably only be ran as an exception and not at all regularly. This issue will be nonexistent for many people as they might not work with compressed files to save storage or their compressed files will not hit the buffer they have left on their SSD. Still, considering that it has been stated again and again that especially on an SSD you want to leave some space free, regularly having KIS fill your SSD to the brink despite one believing to have sufficient buffer at 50-60 GB is certainly not good. As many people could also have significantly a significantly smaller SSD. Anyway the question that now remains is whether KIS will now heed my change of settings on ignoring archives or archives larger than 100 MB. I assume this might not work under a custom test as it will just scan everything, so I am rerunning a full scan now with those settings and will monitor the writes and storage on the SSD. But this is going to take some time, so I don't expect the results today, possibly not even tomorrow but it might also be much faster "IF" Kaspersky now properly skips archives. As this was now, after all, intended behaviour I can see that for users like me or users that have a lot of data, compressed data or limited SSD space, the best solution would be to ignore packed files every time or simply - and probably the best solution - move the TEMP folder to a different drive. I feel partly silly as after all, this was apparently all intentional behaviour by KIS but I also truly believe that something like this should be better documented or optimized. Watching your Drive evaporating before your eyes, unpacking terrabytes of data onto an SSD every time you run a full scan is probably not what your average user would expect. Considering that I believe KIS skips these files only AFTER running out of space on the SSD and then trying to again unpack a file that will not fit the SSD regardless makes this behaviour quite nonsensical anyway. Results for the full scan without scanning archives is pending, I will update again as the older version seems to have had the issue with ignoring my wish to skip over archives. Sorry to have wasted anyone's time, as I said at the very beginning, I did not know whether this behaviour was at all intended but was simply shocked to see my SSD at less than 200 MB of available space. At this point I would however call it poorly implemented or at least poorly documented. Thanks for everyone's help, regardless! Kind regards.
Link to comment
Share on other sites

Flood and Flood's wife
Sorry to have wasted anyone's time, as I said at the very beginning, I did not know whether this behaviour was at all intended but was simply shocked to see my SSD at less than 200 MB of available space. At this point I would however call it poorly implemented or at least poorly documented. Thanks for everyone's help, regardless!. Kind regards.
Hello Kuroi, Thank you for updating. You have not wasted anyone's time. As I said at the beginning your post, your analysis, research & information is valuable and helpful to others. The "intent" of a Community Forum is fully realised when members are given the opportunity to raise issues, exchange information, ideas and sometimes even "solutions". That's also why, if Community members do consult support & are provided with a solution, it benefits others to know that information. Please keep us updated and thank you again. Best regards.
Link to comment
Share on other sites

Not a waste of time at all Kuroi in fact I am very grateful! you are correct. It is a bit silly to use the temp folder for the unpacking. I have a setup as yours. I want to keep the temp folder on the SSD as in many cases it is a good thing (speeds things up nicely - afterall that is the point of an SSD). In the case of programs unpacking huge files to scan then it would be better to try to unpack them in their current folder, do the scan and then delete the temporary file (in my humble opinion). It would be nice to have an option in KAS to tell it to do that or to the default %temp% folder giving the user the choice (but with the default to go to the same folder as the archive file exists initially). Sadly I am not sure how many developers at Kaspersky actually read this forum and of those that do how many may take on board ideas and suggestions such as this. I fear it falls on deaf ears or the ears are not around in the first place (even if you post it as a suggestion). I might be wrong on that though and if I am then I apologise unreservedly to the development team - no disrespect intended :-) Paul
Link to comment
Share on other sites

  • 7 months later...

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now


×
×
  • Create New...