WPR/WPA practically — "पूरा PC slow है" की system-wide performance analysis का परिचय

“उन्होंने कहा नया ऐप install करने के बाद पूरा PC slow हो गया। पर Task Manager देखूँ तो CPU और memory दोनों में जगह है।” “एक PC है जिसे start होने में 3 मिनट लगते हैं। पता ही नहीं क्या गड़बड़ है।” — Performance consulting सचमुच अक्सर इसी आकार में आते हैं। जो बात समान है वह यह कि किसी खास process को देखने से उत्तर नहीं मिलता।

Process-level tools मौजूद हैं। फ़ाइल और registry पहुँच Process Monitor से दिखती है, और .NET ऐप की CPU व GC PerfView से पीछा की जा सकती है। पर “पूरा PC slow है” या “CPU खाली है फिर भी slow” जैसा symptom वहाँ से शुरू होता है जहाँ यह भी पता नहीं कि कौन सा process अपराधी है। ऐप A antivirus scan के कारण slow हो सकता है, या क्योंकि कोई और service disk पर भारी लिख रही है, या कई processes तक फैली lock श्रृंखला के कारण। जो चाहिए वह किसी process के अंदर नहीं बल्कि पूरे OS का एक ही timeline पर record किया data है।

उसे capture और पढ़ने के tools Windows Performance Recorder (WPR) और Windows Performance Analyzer (WPA) हैं। WPR ETW (Event Tracing for Windows) आधार पर OS-wide गतिविधि record करता है, और WPA उस recording को graphs और tables में analyze करता है। किसने किस stack पर CPU इस्तेमाल की, कोई thread किसका wait कर रहा था, किस process ने किस फ़ाइल पर disk I/O जारी की — Task Manager से एक-दो स्तर नीचे के तथ्य timestamps सहित रह जाते हैं।

लघु और मध्यम व्यवसायों के IT staff तथा Windows ऐप developers के लिए, यह लेख WPR से capture की प्रथा और WPA पढ़ने का तरीका — खासकर “जब CPU ऊँची हो” और “जब CPU कम हो फिर भी slow हो” की जाँच का अंतर — अगस्त 2026 की primary sources पर आधारित व्यवस्थित करता है।

1. निष्कर्ष पहले

• “पूरा PC slow है” जाँच का पहला विकल्प WPR/WPA है, जो OS-wide ETW trace capture कर पढ़ता है। Process-level tools (Task Manager, Procmon, PerfView) जो समस्याएँ नहीं पकड़ पाते, हर process और kernel को एक timeline पर देखने से पीछा हो सकती हैं।¹²
• Capture tool wpr.exe Windows 8.1 और बाद में साथ आता है। बिना extra install इस्तेमाल हो सकता है। GUI version (WPRUI) और analysis tool WPA Windows ADK में शामिल हैं।¹²
• मूल प्रक्रिया तीन पंक्तियाँ हैं। Administrator के रूप में wpr -start GeneralProfile -filemode → समस्या reproduce करें → wpr -stop C:\temp\trace.etl। इतना याद रखें तो capture शुरू कर सकते हैं।³
• Field आधार है “customer वातावरण में केवल wpr.exe से capture; पढ़ना अपने machine पर WPA” का विभाजन। उस server पर भी capture हो सकता है जहाँ software install नहीं हो सकता। Packet capture के “standard tool से capture, Wireshark में पढ़ें” जैसा ही विचार है।¹
• WPA पढ़ना “CPU, wait, या I/O” classify करने से शुरू होता है। यदि CPU जल रही हो, CPU Usage (Sampled); यदि CPU खाली हो फिर भी slow, CPU Usage (Precise) में wait analysis; यदि disk संदिग्ध हो, Disk Usage — रास्ता शुरू में बँटता है।⁴⁵
• CPU Usage (Sampled) लगभग हर 1 millisecond sampling से दिखाता है “किस function ने CPU इस्तेमाल की”। Task Manager के “50%” का विवरण process → thread → stack → function चल सकते हैं।⁶
• CPU Usage (Precise) context switch का पूर्ण record है, और बताता है “thread किसका wait कर रहा था”। Waits (wait time), ReadyingProcess (किसने जगाया), और ReadyThreadStack (जगाने वाले का stack) चलना वह तकनीक है जो यह लेख सबसे अधिक पहुँचाना चाहता है।⁴⁷
• Stack पढ़ने के लिए symbol configuration चाहिए। WPA default पर Microsoft के public symbol server को संदर्भित करता है। अपने ऐप के function names देखने के लिए अपने PDB का path जोड़ें।⁸
• ETL फ़ाइल में process names और file paths जैसी internal सिस्टम जानकारी होती है। Capture न्यूनतम आवश्यक रखें, और कंपनी से बाहर जाने पर कैसे संभाला जाएगा, capture से पहले तय करें।

2. Tools कहाँ बैठते हैं — WPR capture करता है, WPA पढ़ता है

Windows Performance Toolkit (WPT) Windows ADK (Windows Assessment and Deployment Kit) में शामिल performance-analysis toolset है; केंद्र WPR और WPA की जोड़ी है।² भूमिकाएँ साफ़ बँटी हैं।

• WPR (Windows Performance Recorder) = capture। यह ETW provider groups को “profile” नामक इकाई में बाँधता है, recording शुरू और रोकता है, और ETL फ़ाइल बनाता है। Command-line version wpr.exe Windows 8.1 और बाद में साथ आता है, बिना extra install। GUI version (WPRUI.exe) ADK में शामिल है।¹
• WPA (Windows Performance Analyzer) = analysis। यह ETL फ़ाइल खोलता है और graphs व tables में analyze करता है। ADK install आवश्यक है।²

दूसरे शब्दों में, customer वातावरण में रखने के लिए कुछ नहीं है। OS-standard wpr.exe से capture करें, ETL फ़ाइल घर ले जाएँ, और अपने PC पर WPA में पढ़ें — packet capture के “pktmon से capture, Wireshark में पढ़ें” जैसा ही विभाजन लागू रहता है।

flowchart TB
    accTitle: WPR से capture और WPA से पढ़ने का विभाजन
    accDescr: Customer वातावरण में OS-standard wpr.exe से record कर ETL फ़ाइल बनाएँ; पार ले जाकर अपने PC पर ADK से install WPA में analysis करें
    subgraph customer["Customer PC（कोई extra install नहीं）"]
        wpr["wpr start → reproduce → stop"] --> etl["ETL फ़ाइल"]
    end
    subgraph office["आपका PC（ADK से WPA）"]
        wpa["Graphs और tables analyze करें"]
    end
    etl -->|"पार ले जाएँ"| wpa

चित्र 1: Customer वातावरण में OS-standard wpr.exe से record कर ETL फ़ाइल बनाएँ; पार ले जाकर अपने PC पर ADK से install WPA में analysis करें।

समान tools से अंतर भी पहले व्यवस्थित करना उपयोगी है।

यदि Procmon “उसने क्या किया” का operation log है और PerfView “.NET के अंदर क्या हुआ”, तो WPA वह tool है जो हर process में “समय कहाँ गायब हुआ” का audit करता है। ETW की mechanics स्वयं, और अपने ऐप को ETW से instrument कैसे करें, “Windows Event Log और ETW का परिचय” में है। यदि आपका ऐप ETW events छोड़ता है, ऐप के checkpoints उसी trace में record होते हैं और उन्हें पंक्तिबद्ध करना बहुत आसान हो जाता है। हालाँकि WPR केवल उन providers के events record करता है जिन्हें आपके चुने recording profile ने enable किया। GeneralProfile आपके अपने providers शामिल नहीं करता, इसलिए यदि उन्हें मिलाना चाहते हैं, अपने providers enable करने वाली custom recording profile (.wprp) तैयार करें और wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile के रूप में जोड़ें, .wprp फ़ाइल के अंदर profile नाम ! से specify कर।³

3. व्यवहार में capture (WPR) — start, reproduce, stop

Administrator terminal में मूल प्रक्रिया।

:: List of built-in profiles you can use
wpr -profiles

:: 1. Start capture (general-purpose profile, file mode)
wpr -start GeneralProfile -filemode

:: 2. Reproduce the issue (check capture status with wpr -status)

:: 3. Stop and save (you can attach a description of the problem).
::    Create the destination folder in advance (without it, -stop fails to save)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "Reproduced the issue where the whole PC becomes slow while starting App X"

:: To abandon without saving
wpr -cancel

-start को जो देते हैं वह profile है, जाँच के लिए आवश्यक ETW providers का bundle।³ अक्सर इस्तेमाल वाले याद रखना पर्याप्त है।⁹

कई profiles एक साथ -start पंक्तिबद्ध कर specify कर सकते हैं (उदाहरण wpr -start GeneralProfile -start FileIO -filemode)।³

flowchart TB
    accTitle: WPR capture flow और mode कैसे चुनें
    accDescr: मौके पर reproduce की जा सकने वाली समस्या file mode में छोटी और reliable capture होती है; अज्ञात समय की समस्या default memory-mode ring buffer में wait की जाती है। Boot या logon की समस्या boot trace इस्तेमाल करती है। हर मामले में start / reproduce / stop प्रक्रिया एक है
    q{"यह कब होता है"}
    q -->|"मौके पर"| file["File mode: छोटी capture"]
    q -->|"समय अज्ञात"| mem["Memory mode: wait（3.1）"]
    q -->|"Boot या logon"| boot["Boot trace（chapter 8）"]
    file --> s1["start → reproduce → stop"]
    mem --> s1

चित्र 2: मौके पर reproduce की जा सकने वाली समस्या file mode में छोटी और reliable capture होती है; अज्ञात समय की समस्या default memory-mode ring buffer में wait की जाती है। Boot या logon की समस्या boot trace इस्तेमाल करती है। हर मामले में start / reproduce / stop प्रक्रिया एक है।

3.1. Memory mode और File mode — क्या reproduce कर सकते हैं, या wait करते हैं

WPR के दो recording-destination modes हैं; default Memory mode (in-memory circular buffer) है। यह ring buffer सबसे पुराने events से overwrite करता है, इसलिए अज्ञात समय की समस्या का wait करते हुए capture चलाते रहने, और होने पर रोकने के लिए उपयुक्त है। -filemode जोड़ने से File mode में switch होता है, और सब कुछ सतत फ़ाइल में record होता है। यह overwrite नहीं होता; एकमात्र छत खाली disk space है, और फ़ाइल बिना सीमा बढ़ती है।¹⁰

flowchart TB
    accTitle: Memory mode और File mode कैसे record करते हैं
    accDescr: Memory mode in-memory circular buffer में record करता है; पुराने events overwrite होते हैं और केवल नवीनतम रहते हैं, इसलिए wait के लिए उपयुक्त। File mode सब कुछ फ़ाइल में रखता है, पर एकमात्र छत खाली disk space है, इसलिए छोटी reliable reproduce के लिए उपयुक्त
    ev["ETW events"] --> ring["Memory mode: ring buffer"]
    ev --> filem["File mode: फ़ाइल बढ़ाएँ"]
    ring -.-> use1["अज्ञात समय की wait"]
    filem -.-> use2["छोटी reliable reproduce"]

चित्र 3: Memory mode in-memory circular buffer में record करता है; पुराने events overwrite होते हैं और केवल नवीनतम रहते हैं, इसलिए wait के लिए उपयुक्त। File mode सब कुछ फ़ाइल में रखता है, पर एकमात्र छत खाली disk space है, इसलिए छोटी reliable reproduce के लिए उपयुक्त।

चुनने का अंगूठे का नियम इस प्रकार है।

• मौके पर reproduce किया जा सकता है → File mode। Reproduce से ठीक पहले शुरू, ठीक बाद रोकें, और capture कुछ मिनटों में रखें
• समय अज्ञात → Memory mode (default) में wait करें। होते ही wpr -stop
• कुछ मिनट का GeneralProfile भी सैकड़ों MB से GB वर्ग की ETL बना सकता है। बहुत बड़ी फ़ाइल WPA में analysis-अयोग्य हो सकती है, इसलिए “जितना लंबा capture उतना बेहतर” उलटा पड़ता है।¹⁰¹¹

GUI से capture के लिए WPRUI शुरू करें, profile और Logging mode चुनें, और Start/Save करें। Official How-to प्रक्रिया सारांशित करता है।¹¹ यदि customer-site संपर्क से capture करवाएँ, ऊपर के तीन command प्रक्रिया में ज्यों के त्यों जा सकते हैं।

4. WPA पढ़ने की मूल बातें — graphs, tables का सुनहरा नियम, और समय संकीर्ण करना

जब capture की ETL WPA में खोलते हैं, बाईं Graph Explorer System Activity, Computation, Storage, और Memory जैसी श्रेणियों में graph thumbnails सूचीबद्ध करता है।¹² देखने वाला graph दाईं Analysis tab पर खींचें, ऊपर graph और नीचे table आती है। पहले तीन बातें ये हैं।

1. Tables का सुनहरा नियम — column क्रम grouping तय करता है। WPA table में दो vertical bars हैं, सोना और नीला, और सोने की bar के बाएँ columns उस क्रम में data को hierarchical (group) करते हैं, और नीली bar के दाएँ columns योग हैं।¹³ उन्हें Process → Stack रखें तो per-process stack योग मिलता है; Stack → Process रखें तो एक ही stack इस्तेमाल करने वाले हर process का योग — columns खींचकर क्रम बदलना स्वयं analysis क्रिया है। यह एक बिंदु समझें तो हर WPA table एक ही तरह पढ़ी जाती है।

flowchart TB
    accTitle: Tables का सुनहरा नियम — दो bars और columns की भूमिका
    accDescr: सोने की bar के बाएँ columns उस क्रम में data hierarchical करते हैं; सोने और नीली bar के बीच display columns हैं; नीली bar के दाएँ columns योग हैं। Columns खींचकर क्रम बदलना स्वयं analysis क्रिया है
    left["सोने के बाएँ: grouping"] --> gold["सोने की bar"]
    gold --> mid["Bars के बीच: display"]
    mid --> blue["नीली bar"]
    blue --> right["नीले के दाएँ: योग"]
    left -.-> op["Analysis के लिए columns खींचें"]

चित्र 4: सोने की bar के बाएँ columns उस क्रम में data hierarchical करते हैं; सोने और नीली bar के बीच display columns हैं; नीली bar के दाएँ columns योग हैं। Columns खींचकर क्रम बदलना स्वयं analysis क्रिया है।

1. समय सीमा संकीर्ण करें। Graph पर खींचकर सीमा चुनें, फिर right-click और “Zoom”, और योग केवल उस अंतराल पर switch होता है। Performance analysis सिद्धांततः हमेशा केवल “वह अंतराल जब समस्या हो रही थी” देखती है (chapter 9)।
2. Symbols configure करें। Stack को function names से पढ़ने के लिए menu से Trace > Load Symbols चलाएँ।¹⁴ Default पर यह Microsoft के public symbol server (msdl.microsoft.com) को संदर्भित करता है, इसलिए internet हो तो Windows के अपने stacks हल हो सकते हैं। अपने ऐप के function names देखने के लिए Trace > Configure Symbol Paths में अपने ऐप के PDB का folder जोड़ें।⁸ PDB क्या है, और Release build के लिए भी उसे हमेशा क्यों रखें, “PDB (Program Database) क्या है” में सार है। .NET Framework NGen native images के लिए WPR capture समय NGen PDB (.ngenpdb) बनाता है और उन्हें trace के पास folder में रखता है, और WPA उन्हें स्वतः संदर्भित करता है।⁸ यह केवल NGen images का तंत्र है, और आपका साधारण JIT .NET ऐप code दायरे से बाहर है। JIT-code address से function name का mapping CLR द्वारा छोड़े JIT events से हल होता है, इसलिए .NET ऐप जाँचते समय CLR provider (Microsoft-Windows-DotNETRuntime और मिलान Rundown) enable करने वाली recording profile (.wprp) तैयार करें और chapter 3 के अपने providers की तरह जोड़ें, wpr -start GeneralProfile -start MyDotNet.wprp!profile-name, ताकि CLR events trace में शामिल हों (स्थानीय WPR कौन सी built-in profiles देता है wpr -profiles से जाँचें)। उसके ऊपर, source पंक्तियों तक mapping के लिए build द्वारा बने PDB रखें, और उन्हें ऊपर के symbol path में जोड़ें।

flowchart TB
    accTitle: Stack को function names से पढ़ने के लिए symbols हल करना
    accDescr: Trace Load Symbols चलाने से Windows स्वयं Microsoft के public symbol server से हल होता है, और आपका ऐप symbol path में जोड़े build PDB से। NGen images WPR द्वारा बने NGen PDB इस्तेमाल करती हैं; JIT .NET code trace के CLR JIT events प्लस build PDB से हल होता है
    load["Trace > Load Symbols"] --> ms["Windows: public symbols"]
    load --> own["अपना ऐप: build PDB"]
    ms -.-> ngen["NGen: WPR .ngenpdb"]
    own -.-> jit["JIT: CLR events + PDB"]

चित्र 5: Trace Load Symbols चलाने से Windows स्वयं Microsoft के public symbol server से हल होता है, और आपका ऐप symbol path में जोड़े build PDB से। NGen images WPR द्वारा बने NGen PDB इस्तेमाल करती हैं; JIT .NET code trace के CLR JIT events प्लस build PDB से हल होता है।

तैयार होने पर अगली शाखा से प्रवेश करते हैं। उस अंतराल में CPU ऊँची थी, या कम? यदि ऊँची, chapter 5 (Sampled); यदि कम फिर भी slow, chapter 6 (Precise)।

flowchart TB
    accTitle: Symptom से WPA graph चुनने की शाखा
    accDescr: समस्या अंतराल पर zoom करें; यदि CPU ऊँची हो तो CPU Usage Sampled पर जाएँ; यदि कम फिर भी slow, single-core / single-thread pin जाँचें फिर CPU Usage Precise में wait analysis; यदि disk संदिग्ध हो, Disk Usage और File IO
    zoom["समस्या अंतराल पर zoom"] --> cpu{"उस अंतराल में CPU"}
    cpu -->|"ऊँची"| sampled["Chapter 5: Sampled"]
    cpu -->|"कम, फिर भी slow"| core{"1-core / 1-thread pin"}
    core -->|"हाँ"| sampled
    core -->|"नहीं"| precise["Chapter 6: Precise"]
    cpu -->|"Disk संदिग्ध"| disk["Chapter 7: disk / file I/O"]

चित्र 6: समस्या अंतराल पर zoom करें; यदि CPU ऊँची हो तो CPU Usage Sampled पर जाएँ; यदि कम फिर भी slow, single-core / single-thread pin जाँचें फिर CPU Usage Precise में wait analysis; यदि disk संदिग्ध हो, Disk Usage और File IO।

5. जब CPU ऊँची हो — CPU Usage (Sampled) से “कौन सा function जल रहा है”

यदि CPU pin हो, जो देखते हैं वह CPU Usage (Sampled) है। यह sampling data है जिसने लगभग हर 1 millisecond हर CPU पर record किया “अब किस process का कौन सा stack चल रहा है”, और sample संख्या का अनुपात CPU समय का विवरण ज्यों का त्यों है।⁶

flowchart TB
    accTitle: CPU Usage Sampled कैसे काम करता है
    accDescr: लगभग हर 1 millisecond हर CPU पर चल रहा stack record होता है, और योगित sample अनुपात CPU समय का विवरण है। Process से thread, stack, और function पढ़ें। Samples के बीच खत्म हुई छोटी गतिविधि दिखाई नहीं देती
    tick["लगभग हर 1 ms interrupt"] --> snap["चल रहे stack record करें"]
    snap --> agg["Sample अनुपात = CPU विवरण"]
    agg --> drill["Process → thread → stack"]
    snap -.-> miss["Samples के बीच गतिविधि छूटती है"]

चित्र 7: लगभग हर 1 millisecond हर CPU पर चल रहा stack record होता है, और योगित sample अनुपात CPU समय का विवरण है। Process से thread, stack, और function पढ़ें। Samples के बीच खत्म हुई छोटी गतिविधि दिखाई नहीं देती।

1. Graph Explorer के Computation से CPU Usage (Sampled) Analysis tab पर रखें और Utilization by Process, Stack preset चुनें।⁵
2. Weight (या Count) descending क्रम में processes देखें। Task Manager में जो “50%” था उसकी पहचान पहले process स्तर पर स्पष्ट होती है।
3. अपराधी process के Stack column का विस्तार करें। Stacks वृक्ष के रूप में योगित होते हैं, और उस path पर चलना जहाँ शाखा पर संख्या अधिक नहीं गिरती आपको CPU जलाने वाले function पर उतारती है। यदि symbols हल हों, अपने code के किस function तक सीधी रेखा है।
4. यदि वृक्ष फैलाना थकाऊ हो, graph display Flame पर switch करें। चौड़ाई = CPU समय का हिस्सा से खींचा जाता है, इसलिए कौन सा call path हावी है एक नज़र में स्पष्ट है। CPU Usage (Sampled) में Flame by Process, Stack preset भी है।¹³

एक सावधानी है। क्योंकि यह sampling है, samples के बीच खत्म हुई छोटी गतिविधि दिखाई नहीं देती।⁶ इसे “समग्र रूप से CPU कहाँ इस्तेमाल हुई” देखने का tool याद रखें, per-invocation अवधि मापने का tool नहीं।

6. जब CPU कम हो फिर भी slow — CPU Usage (Precise) और wait analysis

यह लेख का केंद्र है। Wait analysis पर जाने से पहले एक बात पुष्टि करें। “समग्र CPU usage कम है” का अर्थ “CPU bottleneck नहीं” नहीं है। 16-core PC पर एक core पर pin sequential काम (एक UI thread पूरा दौड़ता) समग्र लगभग 6% ही दिखता है। पहले chapter 5 के Sampled (या CPU Usage (Precise) के Utilization by CPU) में जाँचें कि किसी खास core या thread पर pin नहीं, और यदि नहीं, इस chapter पर आएँ — काम चल नहीं पा रहा नहीं, वह wait कर रहा है। क्या wait बताता है वह CPU Usage (Precise) है।

जहाँ Sampled sampling है, Precise context switch (thread switch) का पूर्ण record है। Thread wait में जाता है, किसी ने जगाया (Ready), और CPU पर उतरता है — वह round trip एक पंक्ति में रहती है, और निम्न columns पढ़ सकते हैं।⁷⁴

flowchart TB
    accTitle: एक wait round trip और columns का मेल
    accDescr: Thread NewThreadStack में बचे stack पर wait में जाता है, और Waits समय wait करता है। जब कोई जगाता है, वह पक्ष ReadyingProcess और ReadyThreadStack में रहता है; CPU contention के लिए Ready समय wait कर फिर चलता है
    run1["चल रहा"] -->|"Wait में जाएँ"| waitst["Wait（Waits us）"]
    waitst -->|"कोई जगाता है"| ready["Ready（CPU contention）"]
    ready -->|"CPU पर उतरता है"| run2["फिर चल रहा"]
    waitst -.-> col["NewThreadStack / ReadyingProcess"]

चित्र 8: Thread NewThreadStack में बचे stack पर wait में जाता है, और Waits समय wait करता है। जब कोई जगाता है, वह पक्ष ReadyingProcess और ReadyThreadStack में रहता है; CPU contention के लिए Ready समय wait कर फिर चलता है।

पढ़ने का pattern इस प्रकार है।⁴

1. Utilization by Process, Thread preset लागू करें और columns में NewThreadStack व ReadyThreadStack जोड़ें।
2. पहले वह thread पहचानें जो delayed operation चला रहा था (UI thread, संबंधित request संभालने वाला thread)। कुल Waits के descending क्रम में केवल देखना भ्रमित करता है, क्योंकि “जानबूझकर पूरे समय wait” करने वाले threads, जैसे message pump या timer, शीर्ष पर रहते हैं। Target thread मिलने पर, यदि उसका CPU Usage (ms) बड़ा हो तो chapter 5 की CPU समस्या है; यदि Waits हावी हों तो wait समस्या।
3. NewThreadStack फैलाएँ और देखें रुकते समय वह क्या कर रहा था। WaitForSingleObject या EnterCriticalSection lock wait है; ReadFile जैसी synchronous I/O के अंदर I/O wait है; socket receive के अंदर साथी के जवाब की wait है।
4. फिर देखें किसने wait छोड़ी। ReadyThreadStack फैलाएँ और ReadyingProcess / ReadyingThreadId जाँचें। यदि kernel के KiTimerExpiration से जगाया गया तो timer था (= timeout तक सोया); यदि I/O completion handle से जगाया गया, वह I/O wait पुष्टि करता है।⁴
5. यदि जगाने वाला पक्ष दूसरा thread या दूसरा process हो, उसी प्रक्रिया से उस thread की जाँच करें। “A lock छोड़ने के लिए B का wait कर रहा था, B C की RPC response का, C disk I/O का” — इस श्रृंखला को जड़ तक चलने पर जो मिलता है वह delay का critical path है।⁷

flowchart TB
    accTitle: Wait analysis में चली जाने वाली critical-path श्रृंखला
    accDescr: Delayed thread A के NewThreadStack में देखें रुकते समय वह क्या कर रहा था, ReadyThreadStack और ReadyingProcess से जगाने वाला B पहचानें, और B की उसी प्रक्रिया से जड़ disk I/O तक जाँच करें
    a["Thread A（delayed काम）"] -->|"Lock wait"| b["Thread B（lock धारण）"]
    b -->|"RPC wait"| c["Process C"]
    c -->|"Sync I/O wait"| d["Disk I/O（जड़）"]
    d -.->|"Completion C जगाती है"| c
    c -.->|"Response B जगाती है"| b
    b -.->|"Lock छोड़ना A जगाता है"| a

चित्र 9: Delayed thread A के NewThreadStack में देखें रुकते समय वह क्या कर रहा था, ReadyThreadStack और ReadyingProcess से जगाने वाला B पहचानें, और B की उसी प्रक्रिया से जड़ disk I/O तक जाँच करें।

“हमने multithread किया और तेज़ नहीं हुआ” जैसे मामलों में यह प्रक्रिया हर worker एक ही lock पर पंक्तिबद्ध ज्यों का त्यों दिखाती है। Design से lock contention बचाना “Practical multithreading best practices: .NET संस्करण” में है, और synchronous I/O में wait के बजाय completion notification पर चलने वाला Windows तंत्र “I/O Completion Ports (IOCP) और .NET Thread Pool” में है। WPA में “किसका wait था” pin कर उन design तर्कों से ठीक करना एक सतत flow है।

7. Disk और file I/O — “कोई disk scan कर रहा है” पहचानना

“पूरा PC slow है” का classic अपराधी CPU नहीं बल्कि disk है। Storage श्रेणी के Disk Usage और File I/O से जाँच करते हैं।¹⁵

Disk Usage disk I/O का record है, और दो columns महत्वपूर्ण हैं। Disk Service Time वह समय है जो disk device ने वास्तव में उस I/O को process करने में लगाया; IO Time वह समय है I/O के OS queue में प्रवेश से पूर्ण होने तक। IO Time हमेशा कम से कम Service Time होता है queue जितना, इसलिए यदि IO Time Service Time से बहुत लंबा हो, वह I/O “queue में wait” कर रहा था।⁶ इतना ही, पर, यह तय नहीं करता कि queue बनाने वाला अपराधी दूसरा process है, या केवल उसी process की भारी I/O slow device पर पंक्तिबद्ध। यहाँ निष्कर्ष न निकालें; Service Time (device की अपनी response) और अगले process, path, और stack विवरण से निपटाएँ।

फिर Utilization by Process, Path Name, Stack preset से देखें किस process ने किस फ़ाइल पर किस stack से I/O जारी की, IO Time या Size के descending क्रम में।¹⁵ Field में अक्सर आने वाले उत्तर ये दो हैं।

• Antivirus हर फ़ाइल scan कर रहा था। जिस खिड़की में ऐप start होने में slow था, antivirus process बड़ी मात्रा में reads जारी करता दिखता है। Process नाम, path, और मात्रा exclusion चर्चा के लिए सबूत ज्यों के त्यों हैं।
• दूसरा process भारी लिख रहा था। Backup, indexer, बहुत अधिक लिखे logs, आदि। लेखन disk तक कब पहुँचता है इसमें cache manager शामिल है, इसलिए “जिस क्षण आपने लिखा” और “जिस क्षण disk व्यस्त है” का विचलन भी “Cache Manager — आपका WriteFile वास्तव में disk तक कब पहुँचता है” में है।

File I/O एक परत ऊपर है, ऐप द्वारा जारी file operations (Create/Read/Write आदि) का record, और Duration by Process, Thread, Type जैसे presets प्रति फ़ाइल नाम और प्रति operation समय योग कर सकते हैं।¹⁵ वह मामला जो file system या filter driver में disk तक पहुँचने से पहले समय खर्च करता है Disk Usage में नहीं आता, इसलिए बेमेल स्वयं — “Disk Usage शांत है पर File I/O slow” — सुराग है। यदि synchronous और async I/O की mechanics से शुरू करना चाहें, “Synchronous और async I/O — OVERLAPPED वास्तव में क्या मतलब है” देखें।

flowchart TB
    accTitle: File IO और Disk Usage जो अलग परतें देखते हैं
    accDescr: ऐप का file operation file system और filter drivers से OS I/O queue होते disk device तक जाता है। File IO ऊपरी परत पर operation record करता है; Disk Usage disk तक पहुँची I/O; IO Time और Disk Service Time का अंतर queue समय है
    app["ऐप: ReadFile / WriteFile"] --> fio["FS और filter（File I/O）"]
    fio --> queue["OS I/O queue"]
    queue --> dev["Disk device（Disk Usage）"]
    fio -.-> n1["Disk Usage से छूटा"]
    queue -.-> n2["IO Time − Service Time"]
    dev -.-> n3["Service Time = device"]

चित्र 10: ऐप का file operation file system और filter drivers से OS I/O queue होते disk device तक जाता है। File IO ऊपरी परत पर operation record करता है; Disk Usage disk तक पहुँची I/O; IO Time और Disk Service Time का अंतर queue समय है।

“शायद memory कम है और swap हो रहा है” की सोच Task Manager और Resource Monitor में पहले isolation पा सकती है, WPA पर जाने से पहले। पर committed memory अकेले से न खारिज करें — commit जगह होने पर भी physical-memory दबाव working set काट सकता है और hard faults जारी रह सकते हैं। उपलब्ध physical memory और Resource Monitor के “Hard Faults/sec” भी जाँचें। उन्हें कैसे पढ़ें “Windows का "memory usage" वास्तव में क्या मतलब है” में है।

8. Slow boot और logon — boot trace का प्रवेश

“Start होने में 3 मिनट लगते हैं” प्रकार हाथ से wpr -start चलाने से पहले खत्म हो जाता है। WPR में boot trace है, और अगले boot पर OS स्वतः recording शुरू करने की व्यवस्था कर सकते हैं।³

:: 1. Arrange automatic recording on the next boot
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Restart (reproduce the slow boot)

:: 3. After boot, stop recording and save (the arrangement is also cleared)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "Issue where boot takes 3 minutes"

flowchart TB
    accTitle: Boot-trace flow
    accDescr: addboot से अगले boot पर automatic recording व्यवस्था कर restart के बाद OS boot पर स्वतः record करता है। Logon बाद stopboot से सहेजना व्यवस्था भी साफ़ करता है। त्यागने के लिए cancelboot से साफ़ करें
    add["wpr -boottrace -addboot"] --> rebootpc["Restart（slow boot）"]
    rebootpc --> auto["OS boot पर record करता है"]
    auto --> stop2["Logon बाद: -stopboot"]
    add -.-> cancel["त्यागें: -cancelboot"]

चित्र 11: addboot से अगले boot पर automatic recording व्यवस्था कर restart के बाद OS boot पर स्वतः record करता है। Logon बाद stopboot से सहेजना व्यवस्था भी साफ़ करता है। त्यागने के लिए cancelboot से साफ़ करें।

Boot और shutdown माप जो पहले xbootmgr के पास था वर्तमान WPR में -onoffscenario Boot जैसे options से भी चल सकता है।³ Capture trace पिछले chapters के समान toolkit से पढ़ा जाता है। Processes graph में timeline पर कौन सा process कब जन्मा देखें, जहाँ boot अटका उस खिड़की पर zoom करें, और CPU, wait, या disk classify करें — श्रृंखला में किसी चीज़ का wait करता startup ऐप, खास I/O पर अटकी service start, आदि दिखने लगते हैं। Boot analysis अपने आप में गहरा specialization क्षेत्र है, इसलिए यह लेख केवल प्रवेश तक जाता है: “हाथ से न पकड़ी जा सकने वाली समस्या भी WPR से capture हो सकती है”। GeneralProfile boot trace से समग्र चित्र पकड़कर शुरू करें।

9. कार्य pattern — classify → zoom → stack, दोहराया

अब जब tools स्पष्ट हैं, पूरी जाँच का pattern यह है।

1. घटना का समय pin करें। “Slow था” नहीं, बल्कि “10:23:40–10:24:10 slow था”। ऐप log, event log, operator का note — कुछ भी चलेगा। यदि आपका ऐप checkpoint ETW या event log में लिखता है, trace के अंदर events ज्यों के त्यों समय के खूँटे बन जाते हैं।
2. केवल उस अंतराल पर zoom करें। पूरे trace का योग औसत हो जाता है, और महत्वपूर्ण विसंगति पतली पड़ती है। WPA analysis हमेशा “असामान्य अंतराल” बनाम “सामान्य अंतराल” की तुलना है।
3. पहले “CPU, wait, या I/O” classify करें। CPU Usage (Sampled) देखें; यदि जल रहा हो, chapter 5। यदि नहीं जल रहा, CPU Usage (Precise) के Waits (chapter 6)। यदि Disk Usage IO Time फूला हो, chapter 7। यह तीन-तरफ़ा काँटा पहले लेने से भटकते नहीं।
4. परिकल्पना → zoom → stack दोहराएँ। यदि सोचें “antivirus?”, उस process तक संकीर्ण करें और stack से पुष्टि करें। यदि न टिके, अगली परिकल्पना। Stack तक चलकर पुष्टि किए बिना निष्कर्ष न निकालना इस तरह की जाँच का अनुशासन है।

flowchart TB
    accTitle: Performance analysis का iterative loop
    accDescr: घटना का समय pin करें, अंतराल पर zoom करें, CPU / wait / I/O classify करें, परिकल्पना बनाकर संकीर्ण करें, और stack से पुष्टि करें। यदि टिके, कारण पुष्ट; यदि नहीं, अगली परिकल्पना से दोहराएँ
    time["समय pin करें"] --> zoomstep["उस अंतराल पर zoom"]
    zoomstep --> triage["CPU / wait / I/O classify करें"]
    triage --> hypo["परिकल्पना और संकीर्ण"]
    hypo --> stack["Stack से पुष्टि"]
    stack -->|"टिकती है"| fix["कारण पुष्ट"]
    stack -->|"नहीं"| hypo

चित्र 12: घटना का समय pin करें, अंतराल पर zoom करें, CPU / wait / I/O classify करें, परिकल्पना बनाकर संकीर्ण करें, और stack से पुष्टि करें। यदि टिके, कारण पुष्ट; यदि नहीं, अगली परिकल्पना से दोहराएँ।

अंत में, capture फ़ाइल का संभाल। ETL फ़ाइल सिस्टम के अंदर को व्यापक रूप से प्रतिबिंबित करती है: हर process के नाम, खुली फ़ाइलों के paths, load modules, और (profile के अनुसार) registry key names। Standard GeneralProfile capture में संचार सामग्री जैसे data शरीर शामिल नहीं, पर यदि custom provider enable किया, उस event का payload (ऐप द्वारा record string आदि) ज्यों का त्यों जाता है। जो providers enable किए वे क्या छोड़ते हैं पुष्टि कर, इसे कंपनी से बाहर जाने लायक confidential फ़ाइल मानें। Packet capture की तरह न्यूनतम आवश्यक capture, प्राप्तकर्ता से सहमति, और retention अवधि व deletion प्रक्रिया में शामिल करें।

flowchart TB
    accTitle: ETL फ़ाइल क्या प्रतिबिंबित करती है, और कैसे संभालें
    accDescr: ETL हर process नाम, खुली फ़ाइलों के paths, modules, और profile के अनुसार registry key names प्रतिबिंबित करता है; custom provider enable करने से उसका payload भी शामिल। Confidential मानें: न्यूनतम आवश्यक capture, दूसरे पक्ष से सहमति, और retention अवधि व deletion
    etl["ETL फ़ाइल"] --> a1["नाम, paths, modules"]
    a1 --> a2["Registry keys（कुछ）"]
    a2 --> a3["Custom payload"]
    a3 -.-> rule["Confidential मानें"]

चित्र 13: ETL हर process नाम, खुली फ़ाइलों के paths, modules, और profile के अनुसार registry key names प्रतिबिंबित करता है; custom provider enable करने से उसका payload भी शामिल। Confidential मानें: न्यूनतम आवश्यक capture, दूसरे पक्ष से सहमति, और retention अवधि व deletion।

10. सारांश

• Task Manager जो “पूरा PC slow” नहीं समझा सकता, OS-wide ETW trace से जाँचा जाता है — WPR से capture, WPA से पढ़ें। wpr.exe Windows 8.1 और बाद में साथ आता है, इसलिए customer वातावरण में capture, ETL घर ले जाना, और अपने machine पर WPA में पढ़ना लागू रहता है।
• Capture तीन कदम है wpr -start GeneralProfile -filemode → reproduce → wpr -stop trace.etl। यदि reproduce कर सकते हैं, कुछ मिनटों में File mode; यदि wait, Memory mode (ring buffer)। लंबा बेहतर नहीं।
• WPA तीन बिंदु लेते ही शुरू हो सकता है: tables का सुनहरा नियम (सोने की bar के बाएँ = grouping), समय सीमा zoom, और symbol configuration (अपने ऐप को PDB चाहिए)।
• यदि CPU ऊँची हो, CPU Usage (Sampled) में process → stack → function चलें। यदि CPU कम फिर भी slow, CPU Usage (Precise) में श्रृंखला NewThreadStack (रुकते समय क्या कर रहा था) → Waits (कितनी देर wait) → ReadyingProcess और ReadyThreadStack (किसने जगाया) जड़ तक चलें।
• Disk के लिए Disk Usage IO Time और Service Time के अंतर से “queue में बिताया समय” देखें, और कारण (device स्वयं slow, या किसने queue बनाई) Service Time तथा process, path, stack विवरण से पहचानें। Slow boot wpr -boottrace से capture हो सकता है।
• कार्य pattern है (1) समय pin करें (2) अंतराल पर zoom (3) CPU, wait, या I/O classify करें (4) परिकल्पना → zoom → stack दोहराएँ। ETL को confidential मानें क्योंकि उसमें internal जानकारी है।

WPA की screen डराती है, और पहले घंटे में सब भटकते हैं। जब दो रीढ़ — “सोने की bar के बाएँ grouping है” और “Sampled जहाँ जला, Precise किसका wait” — बैठ जाएँ, बाकी वही क्रिया दोहराई जाती है। अगली बार जब consulting आए कि “CPU में जगह है फिर भी slow”, Task Manager बंद करें और trace capture करें।

संबंधित लेख

• PerfView और dotnet-trace से “slow” pin करना — .NET performance analysis का practical परिचय
• Process Monitor (ProcMon) की practical guide — 10 मिनट में “setting लागू नहीं” और “ACCESS DENIED” pin करना
• Windows Event Log और ETW का परिचय — व्यावसायिक ऐप के logs OS के standard तंत्र पर रखना
• Windows का “memory usage” वास्तव में क्या मतलब है? — Working Set, Private Bytes, Commit, और page file सही पढ़ना
• Windows Processor Scheduling settings - background services और P/E cores
• PDB (Program Database) क्या है? — debug जानकारी, symbols, और Source Link समझना

संबंधित consulting क्षेत्र

KomuraSoft LLC “पूरा PC slow हो गया और पता नहीं क्यों”, “CPU में जगह है फिर भी ऐप slow”, और “केवल एक खास वातावरण start होने में अत्यंत slow” जैसी system-wide performance समस्याओं की जाँच संभालता है। हम WPR/WPA से capture design (किस वातावरण में, कौन सी profile, कितना capture), trace analysis, और परिणामस्वरूप ऐप पक्ष व setting पक्ष का सुधार एक सतत कार्य के रूप में संभालते हैं।

• Windows ऐप विकास
• बग और कारणों की जाँच
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

WPR और WPA कहाँ से मिलते हैं? क्या उन्हें उस customer वातावरण में इस्तेमाल कर सकते हैं जहाँ software install नहीं हो सकता?

Capture tool wpr.exe (command-line version) Windows 8.1 और बाद में साथ आता है, इसलिए बिना extra install के इस्तेमाल हो सकता है। GUI version WPRUI और analysis tool WPA (Windows Performance Analyzer) Windows ADK (Windows Assessment and Deployment Kit) में शामिल हैं और अलग install चाहिए। व्यवहार में, यदि काम बाँटें "customer वातावरण में केवल OS-standard wpr.exe से ETL फ़ाइल capture करें, घर ले जाएँ, और अपने machine पर WPA में analysis करें", तो उस साइट पर भी system-wide performance analysis हो सकती है जहाँ software नहीं जोड़ सकते।

Task Manager में CPU बचा दिखे तो भी slow क्यों? WPA में क्या दिखता है?

जब CPU usage कम हो और फिर भी slow हो, काम CPU इस्तेमाल नहीं कर पा रहा नहीं — वह "किसी चीज़ का wait" कर रुका है। Lock contention, synchronous I/O पूरा होने की wait, और दूसरे process के जवाब की wait typical हैं। Task Manager केवल परिणाम, usage, दिखाता है; WPA का CPU Usage (Precise) per-context-switch record से दिखाता है कि thread कहाँ wait शुरू हुआ (NewThreadStack), कितनी देर wait किया (Waits), और किसने जगाया (ReadyingProcess, ReadyThreadStack)। जिस पक्ष ने wait कराया उसका पीछा कर "slowness का अपराधी" function तक पहचान सकते हैं।

Trace कितनी देर capture करें? फ़ाइल बहुत बड़ी तो नहीं हो जाएगी?

यदि समस्या reproduce कर सकते हैं, आधार है reproduce से ठीक पहले शुरू करें, ठीक बाद रोकें, और कुछ मिनटों में रखें। WPR का default Memory mode है, जो in-memory circular buffer में record करता है; पुराने events overwrite होते हैं, इसलिए अज्ञात समय की समस्या का wait करने के लिए उपयुक्त है। File mode, -filemode के साथ, सब कुछ सतत फ़ाइल में रखता है, पर एकमात्र छत खाली disk space है, और बहुत बड़ी फ़ाइल WPA में analysis-अयोग्य हो सकती है। लंबी wait के लिए Memory mode, छोटी reliable reproduce के लिए File mode।

PerfView और WPA में कैसे चुनें?

दोनों tools ETW traces संभालते हैं, पर ताकत अलग है। PerfView .NET runtime को गहराई से समझता है और GC, allocation, JIT जैसी managed-ऐप जाँच में मज़बूत है। WPA OS-wide CPU, disk, file I/O, power आदि को graphs और tables में पढ़ने के लिए उपयुक्त है, और पहला विकल्प है जब "कोई खास ऐप नहीं बल्कि पूरा PC slow है", "कई processes शामिल हैं", या "ऐप के बाहर कुछ (antivirus, driver, दूसरा process) संदिग्ध है"। अंगूठे का नियम: अकेले अपने .NET ऐप की सुस्ती के लिए PerfView, पूरे सिस्टम की सुस्ती के लिए WPR/WPA।

क्या customer के production वातावरण में WPR चलाना ठीक है?

छोटी capture व्यवहार में आम है, पर बिना शर्त सुरक्षित नहीं। ETW हल्का है, पर stacks सहित बड़ी मात्रा में events record करने से निश्चित CPU और memory खर्च होता है। Reproduce चरण से ठीक पहले शुरू और ठीक बाद रोकना, capture कुछ मिनटों में रखना, और कम व्यावसायिक प्रभाव वाले समय चलाना — इन्हें किसी सामान्य change जैसी ही approval प्रक्रिया में शामिल करें। साथ ही, ETL फ़ाइल में process names, file paths, executable जानकारी जैसी internal सिस्टम जानकारी होती है, इसलिए कंपनी से बाहर जाने पर कैसे संभाला जाएगा (minimization, retention अवधि, deletion) पहले तय करें।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।