Yüksek Ertelenmiş Prosedür Çağrısının kök nedenine nasıl ulaşabilirim?

Çift çekirdekli bir işlemcime sahibim ve ikisinden biri sürekli olarak% 100'dür. ProcessExplorer'a bakmak bana Ertelenmiş Prosedür Çağrıları olduğunu gösteriyor. İnternette okumak bana tonlarca farklı cevap veriyor gibi görünüyor.

Benim durumumda ne olabileceğini daraltmak için birkaç adım atmak mümkün mü?

Güncelleme 1: FWIW, sorun Güvenli Mod'da bile devam ediyor.

Güncelleme 2: Bilgisayarın arkasından alabildiğim her şeyi çıkardım ve bu bana% 40 daha fazla ücretsiz işlemci aldı. Ayrıca, RATTV3 aracını da indirdim , fakat nedense makinemde bana sürücü bazında bir arıza vermiyor. Burada hem DPCLatencyChecker hem de RATTV3'ün iyi bir açıklaması var .

Güncelleme 3: , LatencyMon (aşağıda benim cevabını bakın) söylüyor bunu en nvstor32.sys- NVidia SATA sürücü olan - 5300 hakkında ms'den süreleri ile.

Güncelleme 4: Grafik bir kurtarma diski önyüklemesinin denenip denenmeyeceğini düşünürken arsa kalınlaşır (gerçekten bir sürücünün olup olmadığını görmek için bir donanım problemi olup olmadığını), DVD / CD çaların çalışmadığını fark ettim (örn. düğmesine bastığımda kapı). Makinenin anakartın değiştirilmesinden yeni döndüğü göz önüne alındığında, belki fişi takmayı unuttuklarını düşündüm. Kutuyu açtım, her şey yolunda görünüyordu, ancak fişi tekrar taktım ve tekrar taktım. Yeniden başlatma sırasında, her şey yolundaydı - artık DPC yok (en yüksek şimdi 300µs)!

Güncelleme 5: Ertesi gün, sorun geri döndü, CD çalar tekrar çalışmıyor, şifre metin kutusundaki imleç bile yavaşça yanıp sönüyor ... Düşünebildiğim her şeyi çıkarmaya çalıştım ve ikinci açılışta tekrar çalıştı (Güncelleme 2'deki gibi) ). Bir dahaki sefere CD çaları tamamen çıkarmayı deneyeceğim ...

Güncelleme 6: Yeni farkedilmiş Sistem olay günlüğü nvstor32.sysbir hata Parity error detected in \Device\RaidPort0mesajı veriyor , ardından yeniden başlatma işlemi hakkında bir uyarı veriyor . Şimdi hangisinin olduğunu bulmak zorundayım RaidPort0... (not, RAID kurulumum yok, sadece bir bataklık standardı Acer.) Oh, ve Avast kurulumum Sistem Geri Alma (ya da ne denirse) yaptığımda görünüşte öldürüldü, çünkü başlamıyor (RPC hatası), kaldırmadı (ayar hatası oluştu).

Güncelleme 7: Sonunda, DVD çıkarılmış olarak yeniden başlatmak için zaman harcadım. Artık DPC problemi yok! (çok fazla sayfa hatası olsa da, ancak bu daha sonra). Bir sonraki adım: Kablo mu yoksa DVD oynatıcı mı?

Güncelleme 8: Bir SATA kablosu ödünç alındı, önyükleme yapıldı, sorun yok. CD / DVD oynatıcı çalışıyor, DPC sorunu nvstor32.sysyok, işlemci yok. Mutlu son ... neredeyse: Avast ile ilgili problemlerim var storport.sys, başlangıçta görünen DPC problemleri (USB için normal olabilir mi?) Ve birçok zor sayfa hatası. Ancak bunlar diğer sorulara konu olacak.

Postscript: Geçenlerde aynı problemi yaşamaya başladım ve aynı yöntemi kullanıp, vurulduğum bir USB çubuğunu (ReadyBoost için kullandığım) izlemeyi başardım.

İşte benim yüksek DPC gecikme nedenini nasıl bulduğumun öyküsü.

Sistemim, ses çalma sırasında tıklamalar ve açılır pencereler yaşıyordu. Bunun çekirdek modundaki bir işlemcinin CPU'yu etkilediğini ifade ettiğini biliyordum. İlk düşüncem, Process Explorer'ı dürtmek ve bir şeylerin yerinde olup olmadığına bakmaktı. Dikkatimi çeken tek şey, Ertelenmiş Prosedür Çağrıları (DPC'ler) yapmak için harcanan zamanın çok fazla olmasıydı:

DPC'lerin bir sürücünün içinde kod çalıştırıldığını biliyordum; zorluk, hangi sürücünün olduğunu bulmaktı. Gecikmenin ne kadar kötü olduğunu gösteren DPC Latency Checker'a döndüm :

DPC Latency Checker , buggy sürücüsünü izole etmeyi umarak Aygıt Yöneticisi'ndeki aygıtlardan geçmeyi ve temel olmayan donanımları tek tek (örneğin ağ kartı, ses kartı) devre dışı bırakmayı önerir . (Bir cihazı devre dışı bırakırsanız ve DPC gecikmesi aniden düşer: suçlunuzu bulursunuz!)

Ne yazık ki, yapabileceğim her şeyi devre dışı bıraktıktan sonra ( bilgisayarı hala kullanabiliyorken - sabit sürücünüzü, ekran kartınızı, farenizi veya USB hub'ınızı devre dışı bırakmayın!), Gecikme süresi hala yüksekti. Daha sonra Windows Performans Araç Takımı'na ( Windows SDK'nın bir parçası ) ve Peter Weiland'ın "DPC Zamanını Ölçme" adlı mükemmel bir blog yazısına döndüm . Windows Performans Araç Takımı'nı yükledikten sonra:

Yükseltilmiş bir komut istemi açtım ve koştum:

>xperf -on Latency

Not : Latency grup bir den izlenebilir etkinlik kümesinin önceden tanımlanmış olan Çekirdek Grubu sağlayıcıya:

>xperf -providers kg
   Base           : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+PROFILE+MEMINFO
   Diag           : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PERF_COUNTER+COMPACT_CSWITCH
   DiagEasy       : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PERF_COUNTER
   Latency        : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PROFILE
   ...

Bu durumda LatencyÇekirdek Bayraklarına karşılık gelir:

• PROC_THREAD İşlem ve iş parçacığı oluşturma / silme
• YÜKLEYİCİ Çekirdek ve kullanıcı modu Image Olayları yükle / kaldır
• PROFİL CPU Örnek profil
• CSWITCH İçerik Anahtarı
• DPC DPC Etkinlikleri
• INTERRUPT Interrupt olayları
• DISK_IO Disk G / Ç
• HARD_FAULTS Zor Sayfa Hataları

Bir dakika boyunca çalışmasına izin verdikten sonra izlemeyi durdurdum ve bir dosyaya kaydettim:

C:\Users\Ian\Desktop\xperf -d thingy1.etl

Ve ardından izlemenin sonuçlarını şu komutla izledim:

C:\Users\Ian\Desktop\xperf thingy1.etl

Bu grafiksel Windows Performance Analyzer'ı yükler . DPC İşlemci Kullanımı grafiğine sağ tıklayarak Özet Tablosunu seçtim . Bu, DPC’lerde sürücü tarafından harcanan zamanın bir dağılımını gösterir:

Hemen bir sürücüyü ( tsvp.sys) DPC uygulaması başına ortalama 2,8 ms alarak görebiliyorum.

Googling tsvp.sysbana cevap verdi: Son zamanlarda yüklediğim CommView .

Şimdi soru, bu sürücünün nasıl devre dışı bırakılacağı. AutoRun'ları kullanarak sürücü servisi olarak yüklendiğini görebiliyorum:

Aygıt Yöneticisi'ni kullanarak bu sürücüyü barındıran hizmeti devre dışı bırakabilirim. Önce gizli aygıtları göster , sonra Non-Plug and Play Driversdüğümü genişlet :

Sonunda sürücü hizmetini durdurabilirim ve başlangıç ​​modunu değiştirdim System(yani, sürücünün Windows'un önemli bir parçası olduğu ve Windows onsuz önyükleme yapamadığı için), Demand(yani istediğimde sürücüyü başlatabilirim):

Sürücü servisini durdurmak derhal DPC gecikmemi düzeltti:

CommView yazılımını tamamen kaldırabilir veya kaldırmayabilirim, ancak şimdilik Yüksek DPC Gecikme Durumunu çözdüm.

Güncelleme : Windows 8 ile başlayarak, artık Aygıt Yöneticisinde Tak ve Çalıştır Olmayan Sürücüleri göremezsiniz :

Not Windows 8 ve Windows Server 2012 ile başlayarak, Tak ve Çalıştır Yöneticisi artık PnP olmayan (eski) cihazlar için cihaz tanımları oluşturmaz. Dolayısıyla, Aygıt Yöneticisi'nde görüntülenecek böyle bir cihaz yoktur. Gizli aygıtları Aygıt Yöneticisi ekranına dahil etmek için Görüntüle'yi tıklatın ve Gizli Aygıtları Göster'i seçin.

Microsoft bu özelliği ortadan kaldırdı ve hiçbir şeyle değiştirmedi. Aferin.

Tipik inek öfkesinde yararsız cevaplar :

• Aygıt yöneticisi hiçbir zaman pnp sürücüsü olmadı
• buna ne için ihtiyacın var?

Neyse ki, NirSoft yerine geçti. ServiWin , tüm servisleri görmenize, durdurmanıza ve başlatmanıza izin verir (Microsoft yöneticilerinin görmesine izin verilmesi gerektiğine karar verdiklerine rağmen):

İLERLEME RAPORU

Şu ana kadar bulduğum en iyi araç , temelde önceki iki aracın yaptığı her şeyi yapan, sizi düşünmeden yapan LatencyMon'dur . İndirme sayfası sizden e-posta yoluyla kaydolmanızı ister - ancak bunu yaptığımda benim için hiçbir şey olmadı - ancak yine de indirmek için sayfanın altına gidebilirsiniz.

Benim durumumda LatencyMon (Benjol'un cevabından) kullandım ve sürücünün hayatı, evreni ve her şeyi dondurduğunu (ayrıca) storport.sys“ yüksek performanslı otobüsler ” için bir Microsoft sürücüsü olduğunu gördüm . Bu, problemin IO ile ilgili olduğundan şüphelendiğimi doğruladı.

Ayrıca devam ettim ve Windows 7 Olay Görüntüleyicime , Windows Logs -> Application klasörüne baktım ve Volume Shadow Copy'den (VSS) her 30 dakikada bir - 2 saatte bir hatalar geldi. Ayrıntılar böyle idi:

Volume Shadow Copy Service error: Error calling a routine on the Shadow Copy Provider {b5946137-7b9f-4925-af80-51abd60b20d5}. Routine returned E_INVALIDARG. Routine details GetSnapshot({00000000-0000-0000-0000-000000000000},000000000023C850). 

Operation:
   Get Shadow Copy Properties

Context:
   Execution Context: Coordinator

Daha sonra haltın ne olduğunu ve ne için kullanıldığını araştırmaya başladım . Oraya gitti birkaç - sayfalarına - yaklaşık - VSS giderme . Büyük bir şüphelinin hepsini geçtikten sonra: yedekleme yazılımım CrashPlan .

Bu ilanın ardından, VSS hatalarıyla ilgili bir sayfayı hızla buldum . VSS kullanan açık dosyaların yedeklenmesini devre dışı bırakmak için verilen talimatları izleyerek, donmalar, yüksek Çekirdek CPU kullanımı vb. Tamamen tükendi. Ve beni yanlış anlama: CrashPlan harika! Sadece bu özellik makinemde çalışmıyordu.

BTW, bu sayfa tam burada, sorunlarımın kök nedenini bulmada bana yardımcı olan ilk ipucunu veren BİRDİR. @Benjol'e ve daha önce yanıtlamış olan herkese çok teşekkürler! Umarım cevabım başkalarına da yardımcı olur ...

Muhtemelen sisteminizi meşgul eden bir aygıt sürücüsü vardır. Bunu analiz etmenin bir yolu DPC gecikme denetleyicisini çalıştırmaktır . Ardından bir seferde bir sürücüyü devre dışı bırakın ve DPC yükünün düşüp düşmediğine bakın. (İşlem gezgini de çalışır.)

Aygıt sürücülerini Bilgisayar Yönetimi -> Aygıt Yöneticisi'nden devre dışı bırakabilirsiniz.

Cevabımı buraya eklemem gerektiğini düşünüyorum çünkü bu sorunun çözülmesi zor ve her zaman kötü sürücülere veya IRQ çatışmalarına bağlı değil.

Toplayıcı yanlısı USB ses kartımda pop / çatlaklara neden olan yüksek RPC gecikme süresi vardı. Kabul edilen cevapta açıklanan araçlar, soruna neden olan belirli bir sürücünün belirlenmesinde yardımcı olmadı. Gecikme, birçok işlemde gerçekleşiyordu: HAL, USBPORT.SYS ve Windows çekirdeği. Bu işlemlere daha derin kazmak, bariz bir suçlu ortaya koymadı.

Benim durumumda, sorunun daha düşük seviyede olduğu ve belirli yonga setleri ve BIOS revizyonları olan GigaByte anakartlarına özgü olduğu ortaya çıktı. Çözüm, Intel SpeedStep'i ve anında CPU hızını ve voltajını ayarlayan diğer tüm anakart özelliklerini devre dışı bırakmaktı. Bu seçenekler kapatıldıktan sonra RPC gecikmem derhal çözüldü.

Grafik kartımı GeForce GTX 550 Ti'ye yükseltirken ortaya çıkan nVidia 10/100/1000 Ethernet denetleyicimde bir IRQ hatasını düzelttikten sonra bu hatayı görmeye başladım.

Yeni GeForce sürücülerine 295.73 yükseltilmesinden ve sonra da kesme ihtilafını çözdükten sonra mevcut nForce SATA / RAID denetleyici sürücülerini kaldırdım, hasar verdim veya kaldırdım. RAID kullanmıyorum, hata devam ediyor ve zaman zaman Vista Ultimate 64-bit'i kilitledi.

İnternette bulduğum tüm sorun giderme önerilerini denedikten sonra basit bir çözüm sundu ... nForce SATA / RAID denetleyicisi 15.58'e yükselttim, ancak diğer nForce sürücülerini yalnız bıraktım.

Bu benim için düzeltti ve şimdi tüm sürücü çatışmalarımı çözdüm. Umarım size de yardımcı olur.