[MagicAndre1981]

it is the same. MediaPortal calls the CPU affinity function and this causes the DPC/ISR issues. But during the time, the CPU is idle and only goes to 1,6GHz (2nd Cool'n'Quiet state)

Is the HighPerformance mode better? I can't really see a difference.

[doveman]

I can't really say the High Performance mode is better yet. I'll leave it in that mode and monitor for glitches for a couple of days, but MediaPortal is still showing continuity errors in it's logs, so if those are being caused by the DPC issues (and you say the .etl capture looks much the same) then High Performance hasn't fixed that.

I'll ask in the Mediaportal forum if they know why it's doing this. Can you expand a bit on the problem so I can describe it better to them (i.e. what you mean by it causing DPC/ISR issues)?

Task Manager shows Mediaportal using 8-14% CPU whilst watching TV by the way, so it's not completely idle.

[doveman]

TV playback kept freezing momentarily tonight, so switching to High Performance hasn't helped. I tried moving the timeshifting files from RAMdisk to HDD as well and that didn't help either.

I've uploaded another capture after a couple of glitches if you could check that for me to see if it looks any different http://www.mediafire...sn666c6taoo633e

[MagicAndre1981]

The MediaPortal may hang becasue it waits. I can see it causes ntkrpamp.exe!KiProcessThreadWaitList calls which calls ntkrpamp.exe!KiReadyThread.

So we must capture ReadyThread data, too.

xperf -on latency+POWER+DISPATCHER -stackwalk profile+CSwitch+ReadyThread -buffersize 1024 -MaxFile 256 -FileMode Circular && timeout -1 && xperf -d DPC_Interrupt.etl

But I must say I never used xperf to analyze hangs. I've uses the Builin profiler of Visual Studio 2010 which uses xperf/ETW in background and shiows me nice list.

[ChristSavesU2]

MagicAndre1981, on 02 July 2012 - 02:49 PM, said:

this is really strange. Can you add a dummy boot entry (clone current one) and add a timeout (1min) to warm up the hardware. Does this also fixes it?

After days of testing and narrowing things down, it does appear to be a temperature issue. After I had the initial problem, I shut down the computer and let it sit for about 3 hours. Started it and it was fine the rest of the day. One morning it was particularly cold and it took almost 25 minutes before I started seeing spikes in DPC times. This morning I turned the computer on and let it sir for 6 minutes before I let it start the boot process (I have an encrypted hard drive that requires a password, so I let it sit on the password prompt) and that was not long enough. It usually starts with a spike in the DPC times around 12 to 15 minutes from start-up. I have attached some informational screen shots at www.willowproperties.net/temp.html 1temp.jpg shows the list of drivers and their highest execution times right after the first spike. 1temp.txt shows the report at that same time. 2temp.jpg shows that the spike was generated from the kernel timer latency versus one of the drivers (not sure what the difference is). 2temp.txt is the report after it has run and the DPC times keep getting worse. 3temp.jpg is the screen shot of the drivers DPC times just before I reboot. You can see that there isn't one particular driver that has high DPC times, there are several. 4temp.jpg shows that both the kernel timer latency and driver DPC latency are both having issues.

The end result is that it seems to be a hardware temperature issue and if I reboot after about 30 minutes of runtime the problem goes away until the machine cools off overnight. Not sure there is a fix. Your thoughts?

Thanks, Ron

[MagicAndre1981]

Run OpenHardwareMonitorand check the temperature of CPU/GPU/Motherboard/HDD:

[ChristSavesU2]

MagicAndre1981, on 07 July 2012 - 10:00 AM, said:

Run OpenHardwareMonitorand check the temperature of CPU/GPU/Motherboard/HDD:

I tried turning on the computer this morning and letting it sit for 30 minutes at the encrypted hard drive password prompt to make sure it was past the warm up time that causes the DPC spike and following degradation. Then when I let if finish booting I found that the DPC latencys were already bad as if I had let it boot in the first place. I downloaded the program you suggested and saved 2 reports. One before I rebooted and one after. And as always, once I rebooted the DPC latency issues are gone and it will run the rest of the day with no problems.

 1temp.txt (18.55K)
Number of downloads: 3

 2temp.txt (18.54K)
Number of downloads: 3

[MagicAndre1981]

this is very confusing. I have no real idea why this is so

[lofagi]

Here im again.

I gave up trying. I sent back my comp where i bought it. They did not found anything wrong. When i got it back did the same things. Fresh windos, but only just 1 driver for Lan. Then i started to torrenting. Then i started to using DPC Latency checker. The problem is gone. Interresting. What is the difference?

- new uTorrent, 3.2 not 3.1.2, and totally new torrents
- still windows soundcard driver
- intel inf, intel mei, intel rapid storage drivers still not installed
- nod32 antivirus and not AVG
- new ATI driver, when the problem was on my comp still just 12-4 release, and now there is a new one, 12-6

This is what are the differences atm.

(And sry for my English again.)

This post has been edited by lofagi: 08 July 2012 - 09:56 AM

[Kessu]

Hi Andre,

got the impression you are the (only) one to save me .

As usual, the story is:
- CPU randomly stalling at +50%
- reboot = fix
- occurs randomly, sometime directly after start, sometime after hours of using, but generally very seldom (like once a week while using PC everyday)
- temperature seems not to be the issue (max 50)
- BIOS, drivers... up to date (as far as i can see)
- All power management settings I was able to find disabled/ set to „max power“

Could you see something interesting in the logs, please? What about the hal.dll?
Logs: https://docs.google....RDEtbFJLZzdZY00

Anyway thank you for help and eternal patience!

This post has been edited by Kessu: 12 July 2012 - 12:23 PM

[ChristSavesU2]

MagicAndre1981, on 08 July 2012 - 09:29 AM, said:

this is very confusing. I have no real idea why this is so

I have found out it is not a temperature issue. I tried letting the computer boot up to the hard drive encryption password, which should only have run the BIOS checks, and then hitting control, alt, delete, to reboot, and then letting it boot up normally from there. Doing this, there are no DPC latency issues all day and the computer works fine. I tried flashing the BIOS and booted normally the next day and the DPC issues are still there, but today I did the immediate reboot and it is working fine. I don't know what the change is when I do the immediate reboot, but it seems to work.

[doveman]

MagicAndre1981, on 05 July 2012 - 02:14 PM, said:

The MediaPortal may hang becasue it waits. I can see it causes ntkrpamp.exe!KiProcessThreadWaitList calls which calls ntkrpamp.exe!KiReadyThread.

So we must capture ReadyThread data, too.

xperf -on latency+POWER+DISPATCHER -stackwalk profile+CSwitch+ReadyThread -buffersize 1024 -MaxFile 256 -FileMode Circular && timeout -1 && xperf -d DPC_Interrupt.etl

But I must say I never used xperf to analyze hangs. I've uses the Builin profiler of Visual Studio 2010 which uses xperf/ETW in background and shiows me nice list.

Hi MagicAndre

I managed to substantially reduce the frequency of the hangs in Mediaportal by disabling all four VMware Player services (VMWare Authorisation Service, VMWare DHCP Service, VMWare NAT Service, VMWare USB Arbitration Service) but the hangs still occur and are as severe, just less frequent. MediaPortal's just been updated to 1.3 Alpha, which might have helped a bit as well. I've uploaded a trace just after one such hang at http://www.mediafire...c2444sa1k4hsh0c

I also checked with LatencyMon (not at the same time) without Mediaportal running and noticed:
Latency stayed under 300 or 400 ms (although I didn't monitor for more than a few minutes)
The highest driver time was ndis.sys at 0.3432 ms, followed by tcpip.sys at 0.19 ms and ntkrnlpa.exe at 0.11 ms. All others were under 0.1 ms. (A later run showed netbt.sys at 0.5 ms and ndis.sys at 0.31 ms).
Highest reported hard pagefault resolution time still seems high at 32394.7125 us.

I've now also uninstalled True Image and will see if that's helped. If not, I'll completely uninstall VMWare Player, as well as Virtualbox as Virtual PC as they all install Virtual NICs (which I have disabled) as well as filter drivers that attach to the real NIC for Bridge Mode, so as my highest times seem to be associated with network components this seems sensible.

I'll wait to hear if you can see anything useful in the trace first though.

[MagicAndre1981]

Kessu, on 12 July 2012 - 12:10 PM, said:

Could you see something interesting in the logs, please? What about the hal.dll?
Logs: https://docs.google....RDEtbFJLZzdZY00

looks like you've uploaded the kernel.etl. This file is useless for me. The file only works on the PC where the data were captured.

[MagicAndre1981]

ChristSavesU2, on 12 July 2012 - 12:12 PM, said:

I tried letting the computer boot up to the hard drive encryption password, which should only have run the BIOS checks, and then hitting control, alt, delete, to reboot, and then letting it boot up normally from there.

can you disable this hard drive encryption password? Does this make a difference?

[MagicAndre1981]

doveman, on 12 July 2012 - 02:31 PM, said:

I managed to substantially reduce the frequency of the hangs in Mediaportal by disabling all four VMware Player services (VMWare Authorisation Service, VMWare DHCP Service, VMWare NAT Service, VMWare USB Arbitration Service) but the hangs still occur and are as severe, just less frequent. MediaPortal's just been updated to 1.3 Alpha, which might have helped a bit as well. I've uploaded a trace just after one such hang at http://www.mediafire...c2444sa1k4hsh0c

I also checked with LatencyMon (not at the same time) without Mediaportal running and noticed:
Latency stayed under 300 or 400 ms (although I didn't monitor for more than a few minutes)
The highest driver time was ndis.sys at 0.3432 ms, followed by tcpip.sys at 0.19 ms and ntkrnlpa.exe at 0.11 ms. All others were under 0.1 ms. (A later run showed netbt.sys at 0.5 ms and ndis.sys at 0.31 ms).
Highest reported hard pagefault resolution time still seems high at 32394.7125 us.

DPCs should be no issue.

MediaPortla uses Timers which do some .Net Remoting (SOAP) calls (System.Runtime.Serialization.Formatters.Soap.dll!?) which seems to block the tool. I think such a coding issue causes the hangs.

[doveman]

MagicAndre1981, on 12 July 2012 - 03:20 PM, said:

doveman, on 12 July 2012 - 02:31 PM, said:

I managed to substantially reduce the frequency of the hangs in Mediaportal by disabling all four VMware Player services (VMWare Authorisation Service, VMWare DHCP Service, VMWare NAT Service, VMWare USB Arbitration Service) but the hangs still occur and are as severe, just less frequent. MediaPortal's just been updated to 1.3 Alpha, which might have helped a bit as well. I've uploaded a trace just after one such hang at http://www.mediafire...c2444sa1k4hsh0c

I also checked with LatencyMon (not at the same time) without Mediaportal running and noticed:
Latency stayed under 300 or 400 ms (although I didn't monitor for more than a few minutes)
The highest driver time was ndis.sys at 0.3432 ms, followed by tcpip.sys at 0.19 ms and ntkrnlpa.exe at 0.11 ms. All others were under 0.1 ms. (A later run showed netbt.sys at 0.5 ms and ndis.sys at 0.31 ms).
Highest reported hard pagefault resolution time still seems high at 32394.7125 us.

DPCs should be no issue.

MediaPortla uses Timers which do some .Net Remoting (SOAP) calls (System.Runtime.Serialization.Formatters.Soap.dll!?) which seems to block the tool. I think such a coding issue causes the hangs.

It seems unlikely, as many people use Mediaportal to watch TV without having this problem. Disabling those VMWare services seems to have substantially reduced the frequency of the hangs and I recall VMWare Workstartion caused latency problems for me previously that messed up Mediaportal.

Anyway, this is what the MediaPortal developers have told me:

"EVR presenter calls SetThreadAffinityMask() to workaround some buggy bios / HW -> http://msdn.microsof.../ms644904(VS.85).aspx. In any case it is perfectly valid to call that method, if it triggers some issue then there must be some underlying issue with the HW (or most likely drivers).

ISR/DPC <-- those are both kernel level stuff. ISR == interrupt service routine, DPC == deferred procedure call. Both are something that MediaPortal (or any other user mode program) cannot difrectly trigger.

After 1.3.0 alpha is out (and you have updated to it) I can build a dshowhelper. dll without that one specific call for testing. The side effect is that it would probably break lot of older systems that are currently working ok (we don't have any clue what HW Microsoft is talking about). It will require quite big amount of testing to be able to remove that workaround from the code - it will affect the video frame scheduling accuracy.

In any case I would say that there is some driver level issue on the system where you see the ISR/DPC spikes. "

[ChristSavesU2]

MagicAndre1981, on 12 July 2012 - 02:59 PM, said:

can you disable this hard drive encryption password? Does this make a difference?

The only way to disable the encryption password would be to decrypt the hard drive. What I did try was to not let the BIOS get completely through its process and turned off the computer before it got to the encryption password prompt. Then switched it back on and let it boot normally. That worked as well, no DPC latency issues all day.

[Kessu]

MagicAndre1981, on 12 July 2012 - 02:57 PM, said:

Kessu, on 12 July 2012 - 12:10 PM, said:

Could you see something interesting in the logs, please? What about the hal.dll?
Logs: https://docs.google....RDEtbFJLZzdZY00

looks like you've uploaded the kernel.etl. This file is useless for me. The file only works on the PC where the data were captured.

For sure no,t as:

1) can parse the file on another PC
2) dont know, how to create kernel.etl

The only strange thing is that the log is cumulated in the beggining of time axis even thou it has logged something like 5 minutes. Not sure if the time axis labels are seconds...

Anywa will try to log once more, when the isuue occur.

Thanks so far!

[MagicAndre1981]

Kessu, on 15 July 2012 - 02:36 AM, said:

Anywa will try to log once more, when the isuue occur.

do you run LatencyMon in background?

[Kessu]

MagicAndre1981, on 15 July 2012 - 08:24 AM, said:

do you run LatencyMon in background?

Not during this log.

I made this error before, however got just error message from xperf, google helped me to find the reason. This log is without latencymon running. Only if there is some service... might be the case (havent check that).

This post has been edited by Kessu: 15 July 2012 - 09:12 AM