New
#71
Lool thanks unfortunately thanks to my rotten cable tv provider i cannot fully enjoy tv captures, but that's offtopic here so nevermind :) But at least the dropped frames issue is solved for now.
Periodic freezes in my system
-
-
New #72
This has been a great thread! Great detective work!
Just to add my 2¢... you are not alone in your Kaspersky issues. I was getting 3, 4, 5 BSODs per day back in June, and dumping Kaspersky solved about half of them. The new av/as from MS (Microsoft Security Essentials) works good with Win 7... give it a try. You won't even notice its there... the best thing you can say about an av/as utility.
-
New #73
ok thanks i will try it later.
-
New #74
Jeez both the "none (buffered)" and "full" methods are VERY good indeed... last nigh i did a NINE hour capture (yes you all read correctly!!) with ZERO dropped frames! And i also tested while doing several things on the pc and EVEN opening and closing the dvd tray which ALWAYS used to trigger dropped frames, but now none got dropped and no, there wasn't any problem in the capture file at all! Yeah i am sure happy with this now it's even better than in windows xp, finally.
-
New #75
Very interesting investigation!Good news: the nature of the "midnight" freeze is easy to see in the logs.
Bad news: Insufficient info (in Xperf) to tell which driver is responsible
Suggestion: do the "midnight" capture once more please, but this time crash the box on purpose afterwards so that a BSOD minidump is generated (once you've saved your data). Here's how...
1) Add the "CrashOnCtrlScroll" registry value as per this MSDN article: Forcing a System Crash from the Keyboard
2) Reboot at least once. Test that your machine then bugchecks (BSODs) whenever you press ctrl+ScrLk+ScrLk, and that it produces a minidump in \Windows\Minidump. (The minidump is the important part.)
3) For the next "midnight run", use: xperf -on PROC_THREAD+LOADER+INTERRUPT+DPC+PROFILE+DISPATCHER+DRIVERS+CSWITCH -stackwalk profile
4) A few minutes after you finish and save the Xperf logging, use ctrl+ScrLk+ScrLk to crash the machine and produce a minidump.
It's *vital* that the Xperf log and minidump be from the same boot. In other words, the crash has to occur after you run Xperf, but before you reboot. The combination of Xperf log and minidump may reveal more.
=================
Longer version: you can see in the attached graph, which is a composite of several overlaid quantities, that everything else seems to cease during that phallic-looking "DPC" spike (in red). Think of a DPC as a very primitive and high-priority task that temporarily suspends everything else on the system. They normally occur somewhere between 200 and 500 times per second on your machine, but during the 1sec interval around that spike there are in excess of 98 thousand DPCs. Their combined effect is the temporary lockup that you experience - the system is so busy servicing DPCs that all other activity is basically suspended.
The table I attached shows the address of the function responsible as 0x8e4536c0. That's outside of the kernel range, and very probably a driver. The problem is that I can't tell which driver because of a randomisation feature that moves those addresses around on each boot (partially for security reasons). That's why the combination of Xperf log plus minidump may reveal which driver is involved - the minidump can be used to correlate the address to a particular driver name.
I have no idea whether this will lead to a practical solution, but hell, it's fun (at least for me
), and it may even pinpoint the hardware/driver combo that's doing weird stuff at midnight.
However, sorting the DPC CPU usage summary table (from the Xperf trace) by modules rather than by functions would have shown directly that kl1.sys was the culprit without having to create a minidump and load it in windbg to find this same module from the function's address..
Last edited by kernelist; 15 Feb 2010 at 05:06.
-
New #76
Excuse me from reviving this old thread, but I've been having the same "midnight freeze" issue for a year now, since I have Vista Business 64 bit (currently at SP2). I've decided to Google it once more after getting a freeze while playing at 00:00 today and found your discussion.
I have KAV11 (11.0.1.400), not KIS. I see it has been found Kaspersky, more specifically kl1.sys, is the culprit, nice work! Why is it doing this all the time at midnight though? Is there somewhere in Kaspersky's options we could perhaps change to stop this from happening? Some automatic, predetermined task we could disable?
Thanks
-
New #77
Well unfortunately i don't know how to help you because quite honestly i STILL have the same problem even now in windows 7 32bits and having a quad core amd 955 be cpu and KIS 2010, and i learned to "live with that freeze" mostly because i don't do anymore cpu based tv capturing and it's all using a hardware encoder tv capture card so i haven't worried about this problem anymore, and i am glad about that because i haven't found a way to fix this at all.
By the way the only reason i don't use KIS 2011 at all is because many times i get 100% cpu (in fact 25% of it since i have now a quad core) usage and i don't have that problem in kis 2010, but the freezes at midnight still happen unfortunately.
Quote
Related Discussions