WPR और WPA कहाँ से मिलते हैं? क्या उन्हें उस ग्राहक वातावरण में इस्तेमाल कर सकते हैं जहाँ सॉफ़्टवेयर इंस्टॉल नहीं हो सकता?

कैप्चर टूल wpr.exe (कमांड-लाइन संस्करण) Windows 8.1 और बाद में साथ आता है, इसलिए बिना अतिरिक्त इंस्टॉल के उपयोग हो सकता है। GUI संस्करण WPRUI और विश्लेषण टूल WPA (Windows Performance Analyzer) Windows ADK (Windows Assessment and Deployment Kit) में शामिल हैं और अलग इंस्टॉल चाहिए। व्यवहार में, यदि काम बाँटें "ग्राहक वातावरण में केवल OS-मानक wpr.exe से ETL फ़ाइल कैप्चर करें, घर ले जाएँ, और अपने मशीन पर WPA में विश्लेषण करें", तो उस साइट पर भी सिस्टम-व्यापी प्रदर्शन जाँच हो सकती है जहाँ सॉफ़्टवेयर नहीं जोड़ सकते।

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

जब CPU उपयोग कम हो और फिर भी धीमा हो, काम CPU इस्तेमाल नहीं कर पा रहा नहीं — वह "किसी चीज़ का इंतज़ार" कर रुका है। लॉक विवाद, सिंक्रोनस I/O पूरा होने की प्रतीक्षा, और दूसरे प्रोसेस के जवाब की प्रतीक्षा विशिष्ट हैं। Task Manager केवल परिणाम, उपयोग, दिखाता है; WPA का CPU Usage (Precise) प्रति-कॉन्टेक्स्ट-स्विच रिकॉर्ड से दिखाता है कि थ्रेड कहाँ इंतज़ार शुरू हुआ (NewThreadStack), कितनी देर इंतज़ार किया (Waits), और किसने जगाया (ReadyingProcess, ReadyThreadStack)। जिस पक्ष ने इंतज़ार कराया उसका पीछा कर "धीमेपन का अपराधी" फ़ंक्शन तक पहचान सकते हैं।

ट्रेस कितनी देर कैप्चर करें? फ़ाइल बहुत बड़ी तो नहीं हो जाएगी?

यदि समस्या दोहरा सकते हैं, आधार है पुनरुत्पादन से ठीक पहले शुरू करें, ठीक बाद रोकें, और कुछ मिनटों में रखें। WPR का डिफ़ॉल्ट Memory मोड है, जो इन-मेमोरी सर्कुलर बफ़र में रिकॉर्ड करता है; पुराने इवेंट ओवरराइट होते हैं, इसलिए अज्ञात समय की समस्या का इंतज़ार करने के लिए उपयुक्त है। File मोड, -filemode के साथ, सब कुछ सतत फ़ाइल में रखता है, पर एकमात्र छत खाली डिस्क स्थान है, और बहुत बड़ी फ़ाइल WPA में विश्लेषण-अयोग्य हो सकती है। लंबी प्रतीक्षा के लिए Memory मोड, छोटी विश्वसनीय पुनरुत्पादन के लिए File मोड।

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

दोनों टूल ETW ट्रेस सँभालते हैं, पर ताकत अलग है। PerfView .NET रनटाइम को गहराई से समझता है और GC, आवंटन, JIT जैसी managed-ऐप जाँच में मज़बूत है। WPA OS-व्यापी CPU, डिस्क, फ़ाइल I/O, पावर आदि को ग्राफ़ और तालिकाओं में पढ़ने के लिए उपयुक्त है, और पहला विकल्प है जब "कोई खास ऐप नहीं बल्कि पूरा PC धीमा है", "कई प्रोसेस शामिल हैं", या "ऐप के बाहर कुछ (एंटीवायरस, ड्राइवर, दूसरा प्रोसेस) संदिग्ध है"। अंगूठे का नियम: अकेले अपने .NET ऐप की सुस्ती के लिए PerfView, पूरे सिस्टम की सुस्ती के लिए WPR/WPA।

क्या ग्राहक के प्रोडक्शन वातावरण में WPR चलाना ठीक है?

छोटी कैप्चर व्यवहार में आम है, पर बिना शर्त सुरक्षित नहीं। ETW हल्का है, पर स्टैक सहित बड़ी मात्रा में इवेंट रिकॉर्ड करने से निश्चित CPU और मेमोरी खर्च होता है। पुनरुत्पादन चरण से ठीक पहले शुरू और ठीक बाद रोकना, कैप्चर कुछ मिनटों में रखना, और कम व्यावसायिक प्रभाव वाले समय चलाना — इन्हें किसी सामान्य परिवर्तन जैसी ही स्वीकृति प्रक्रिया में शामिल करें। साथ ही, ETL फ़ाइल में प्रोसेस नाम, फ़ाइल पथ, एक्ज़ीक्यूटेबल जानकारी जैसी आंतरिक सिस्टम जानकारी होती है, इसलिए कंपनी से बाहर जाने पर कैसे सँभाला जाएगा (न्यूनतमकरण, प्रतिधारण अवधि, विलोपन) पहले तय करें।

WPR/WPA व्यवहार में — "पूरा PC धीमा है" की सिस्टम-व्यापी प्रदर्शन जाँच का परिचय

21 Aug 2026 00:05 · Go Komura · Windows, प्रदर्शन, WPR, WPA, ETW, प्रदर्शन जाँच, समस्या निवारण, Windows विकास

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

प्रोसेस-स्तरीय टूल मौजूद हैं। फ़ाइल और रजिस्ट्री पहुँच Process Monitor से दिखती है, और .NET ऐप की CPU व GC PerfView से पीछा की जा सकती है। पर “पूरा PC धीमा है” या “CPU खाली है फिर भी धीमा” जैसा लक्षण वहाँ से शुरू होता है जहाँ यह भी पता नहीं कि कौन सा प्रोसेस अपराधी है। ऐप A एंटीवायरस स्कैन के कारण धीमा हो सकता है, या क्योंकि कोई और सेवा डिस्क पर भारी लिख रही है, या कई प्रोसेस तक फैली लॉक श्रृंखला के कारण। जो चाहिए वह किसी प्रोसेस के अंदर नहीं बल्कि पूरे OS का एक ही टाइमलाइन पर रिकॉर्ड किया डेटा है।

उसे कैप्चर और पढ़ने के टूल Windows Performance Recorder (WPR) और Windows Performance Analyzer (WPA) हैं। WPR ETW (Event Tracing for Windows) आधार पर OS-व्यापी गतिविधि रिकॉर्ड करता है, और WPA उस रिकॉर्डिंग को ग्राफ़ और तालिकाओं में विश्लेषित करता है। किसने किस स्टैक पर CPU इस्तेमाल की, कोई थ्रेड किसका इंतज़ार कर रहा था, किस प्रोसेस ने किस फ़ाइल पर डिस्क I/O जारी की — Task Manager से एक-दो स्तर नीचे के तथ्य टाइमस्टैम्प सहित रह जाते हैं।

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

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

“पूरा PC धीमा है” जाँच का पहला विकल्प WPR/WPA है, जो OS-व्यापी ETW ट्रेस कैप्चर कर पढ़ता है। प्रोसेस-स्तरीय टूल (Task Manager, Procmon, PerfView) जो समस्याएँ नहीं पकड़ पाते, हर प्रोसेस और कर्नेल को एक टाइमलाइन पर देखने से पीछा हो सकती हैं।¹²
कैप्चर टूल wpr.exe Windows 8.1 और बाद में साथ आता है। बिना अतिरिक्त इंस्टॉल उपयोग हो सकता है। GUI संस्करण (WPRUI) और विश्लेषण टूल WPA Windows ADK में शामिल हैं।¹²
मूल प्रक्रिया तीन पंक्तियाँ हैं। व्यवस्थापक के रूप में wpr -start GeneralProfile -filemode → समस्या दोहराएँ → wpr -stop C:\temp\trace.etl। इतना याद रखें तो कैप्चर शुरू कर सकते हैं।³
फ़ील्ड आधार है “ग्राहक वातावरण में केवल wpr.exe से कैप्चर; पढ़ना अपने मशीन पर WPA” का विभाजन। उस सर्वर पर भी कैप्चर हो सकता है जहाँ सॉफ़्टवेयर इंस्टॉल नहीं हो सकता। पैकेट कैप्चर के “मानक टूल से कैप्चर, Wireshark में पढ़ें” जैसा ही विचार है।¹
WPA पढ़ना “CPU, प्रतीक्षा, या I/O” वर्गीकृत करने से शुरू होता है। यदि CPU जल रही हो, CPU Usage (Sampled); यदि CPU खाली हो फिर भी धीमा, CPU Usage (Precise) में प्रतीक्षा विश्लेषण; यदि डिस्क संदिग्ध हो, Disk Usage — रास्ता शुरू में बँटता है।⁴⁵
CPU Usage (Sampled) लगभग हर 1 मिलीसेकंड सैंपलिंग से दिखाता है “किस फ़ंक्शन ने CPU इस्तेमाल की”। Task Manager के “50%” का विवरण प्रोसेस → थ्रेड → स्टैक → फ़ंक्शन चल सकते हैं।⁶
CPU Usage (Precise) कॉन्टेक्स्ट स्विच का पूर्ण रिकॉर्ड है, और बताता है “थ्रेड किसका इंतज़ार कर रहा था”। Waits (प्रतीक्षा समय), ReadyingProcess (किसने जगाया), और ReadyThreadStack (जगाने वाले का स्टैक) चलना वह तकनीक है जो यह लेख सबसे अधिक पहुँचाना चाहता है।⁴⁷
स्टैक पढ़ने के लिए सिंबल कॉन्फ़िगरेशन चाहिए। WPA डिफ़ॉल्ट पर Microsoft के सार्वजनिक सिंबल सर्वर को संदर्भित करता है। अपने ऐप के फ़ंक्शन नाम देखने के लिए अपने PDB का पथ जोड़ें।⁸
ETL फ़ाइल में प्रोसेस नाम और फ़ाइल पथ जैसी आंतरिक सिस्टम जानकारी होती है। कैप्चर न्यूनतम आवश्यक रखें, और कंपनी से बाहर जाने पर कैसे सँभाला जाएगा, कैप्चर से पहले तय करें।

2. टूल कहाँ बैठते हैं — WPR कैप्चर करता है, WPA पढ़ता है

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

WPR (Windows Performance Recorder) = कैप्चर। यह ETW प्रदाता समूहों को “प्रोफ़ाइल” नामक इकाई में बाँधता है, रिकॉर्डिंग शुरू और रोकता है, और ETL फ़ाइल बनाता है। कमांड-लाइन संस्करण wpr.exe Windows 8.1 और बाद में साथ आता है, बिना अतिरिक्त इंस्टॉल। GUI संस्करण (WPRUI.exe) ADK में शामिल है।¹
WPA (Windows Performance Analyzer) = विश्लेषण। यह ETL फ़ाइल खोलता है और ग्राफ़ व तालिकाओं में विश्लेषित करता है। ADK इंस्टॉल आवश्यक है।²

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

flowchart TB
    accTitle: WPR से कैप्चर और WPA से पढ़ने का विभाजन
    accDescr: ग्राहक वातावरण में OS-मानक wpr.exe से रिकॉर्ड कर ETL फ़ाइल बनाएँ; पार ले जाकर अपने PC पर ADK से इंस्टॉल WPA में विश्लेषण करें
    subgraph customer["ग्राहक PC（कोई अतिरिक्त इंस्टॉल नहीं）"]
        wpr["wpr start → दोहराएँ → stop"] --> etl["ETL फ़ाइल"]
    end
    subgraph office["आपका PC（ADK से WPA）"]
        wpa["ग्राफ़ और तालिकाएँ विश्लेषित करें"]
    end
    etl -->|"पार ले जाएँ"| wpa

चित्र 1: ग्राहक वातावरण में OS-मानक wpr.exe से रिकॉर्ड कर ETL फ़ाइल बनाएँ; पार ले जाकर अपने PC पर ADK से इंस्टॉल WPA में विश्लेषण करें।

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

	Process Monitor	PerfView	WPR + WPA
जो प्रश्न वह उत्तर देता है	किस प्रोसेस ने किस पथ पर क्या किया, और क्या हुआ	.NET ऐप की CPU, GC, और आवंटन कैसी दिख रही है	पूरे OS में समय कहाँ गायब हुआ
दायरा	फ़ाइल, रजिस्ट्री, और प्रोसेस स्टार्ट का ऑपरेशन लॉग	पहले managed कोड	सिस्टम-व्यापी CPU, प्रतीक्षा, डिस्क, फ़ाइल I/O, पावर आदि
उपयुक्त लक्षण	सेटिंग नहीं पढ़ी जा रही, ACCESS DENIED	अकेले अपने .NET ऐप की सुस्ती या मेमोरी	पूरा PC धीमा, CPU खाली फिर भी धीमा, अपराधी प्रोसेस अज्ञात
लेख	Procmon की व्यावहारिक मार्गदर्शिका	PerfView का व्यावहारिक परिचय	यह लेख

यदि Procmon “उसने क्या किया” का ऑपरेशन लॉग है और PerfView “.NET के अंदर क्या हुआ”, तो WPA वह टूल है जो हर प्रोसेस में “समय कहाँ गायब हुआ” का ऑडिट करता है। ETW की यांत्रिकी स्वयं, और अपने ऐप को ETW से इंस्ट्रूमेंट कैसे करें, “Windows Event Log और ETW का परिचय” में है। यदि आपका ऐप ETW इवेंट छोड़ता है, ऐप के चेकपॉइंट उसी ट्रेस में रिकॉर्ड होते हैं और उन्हें पंक्तिबद्ध करना बहुत आसान हो जाता है। हालाँकि WPR केवल उन प्रदाताओं के इवेंट रिकॉर्ड करता है जिन्हें आपके चुने रिकॉर्डिंग प्रोफ़ाइल ने सक्षम किया। GeneralProfile आपके अपने प्रदाता शामिल नहीं करता, इसलिए यदि उन्हें मिलाना चाहते हैं, अपने प्रदाता सक्षम करने वाली कस्टम रिकॉर्डिंग प्रोफ़ाइल (.wprp) तैयार करें और wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile के रूप में जोड़ें, .wprp फ़ाइल के अंदर प्रोफ़ाइल नाम ! से निर्दिष्ट कर।³

3. व्यवहार में कैप्चर (WPR) — start, दोहराएँ, stop

व्यवस्थापक टर्मिनल में मूल प्रक्रिया।

:: 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 को जो देते हैं वह प्रोफ़ाइल है, जाँच के लिए आवश्यक ETW प्रदाताओं का बंडल।³ अक्सर इस्तेमाल वाले याद रखना पर्याप्त है।⁹

प्रोफ़ाइल	वह क्या रिकॉर्ड करती है	कब इस्तेमाल करें
`GeneralProfile`	CPU सैंपल, कॉन्टेक्स्ट स्विच, और डिस्क I/O सहित सामान्य-उद्देश्य सेट	यहीं से शुरू करें। जब पता न हो क्या गलत है, पहला कदम
`CPU`	विस्तृत CPU उपयोग	जब पहले से पता हो CPU जल रही है
`DiskIO`	डिस्क I/O गतिविधि	जब डिस्क संदिग्ध हो
`FileIO`	फ़ाइल I/O गतिविधि	जब देखना हो किस फ़ाइल तक पहुँच हो रही है

कई प्रोफ़ाइल एक साथ -start पंक्तिबद्ध कर निर्दिष्ट कर सकते हैं (उदाहरण wpr -start GeneralProfile -start FileIO -filemode)।³

flowchart TB
    accTitle: WPR कैप्चर प्रवाह और मोड कैसे चुनें
    accDescr: मौके पर दोहराई जा सकने वाली समस्या फ़ाइल मोड में छोटी और विश्वसनीय कैप्चर होती है; अज्ञात समय की समस्या डिफ़ॉल्ट मेमोरी-मोड रिंग बफ़र में इंतज़ार की जाती है। बूट या लॉगऑन की समस्या बूट ट्रेस उपयोग करती है। हर मामले में start / दोहराएँ / stop प्रक्रिया एक है
    q{"यह कब होता है"}
    q -->|"मौके पर"| file["फ़ाइल मोड: छोटी कैप्चर"]
    q -->|"समय अज्ञात"| mem["मेमोरी मोड: प्रतीक्षा（3.1）"]
    q -->|"बूट या लॉगऑन"| boot["बूट ट्रेस（अध्याय 8）"]
    file --> s1["start → दोहराएँ → stop"]
    mem --> s1

चित्र 2: मौके पर दोहराई जा सकने वाली समस्या फ़ाइल मोड में छोटी और विश्वसनीय कैप्चर होती है; अज्ञात समय की समस्या डिफ़ॉल्ट मेमोरी-मोड रिंग बफ़र में इंतज़ार की जाती है। बूट या लॉगऑन की समस्या बूट ट्रेस उपयोग करती है। हर मामले में start / दोहराएँ / stop प्रक्रिया एक है।

3.1. Memory मोड और File मोड — क्या दोहरा सकते हैं, या प्रतीक्षा करते हैं

WPR के दो रिकॉर्डिंग-गंतव्य मोड हैं; डिफ़ॉल्ट Memory मोड (इन-मेमोरी सर्कुलर बफ़र) है। यह रिंग बफ़र सबसे पुराने इवेंट से ओवरराइट करता है, इसलिए अज्ञात समय की समस्या का इंतज़ार करते हुए कैप्चर चलाते रहने, और होने पर रोकने के लिए उपयुक्त है। -filemode जोड़ने से File मोड में स्विच होता है, और सब कुछ सतत फ़ाइल में रिकॉर्ड होता है। यह ओवरराइट नहीं होता; एकमात्र छत खाली डिस्क स्थान है, और फ़ाइल बिना सीमा बढ़ती है।¹⁰

flowchart TB
    accTitle: Memory मोड और File मोड कैसे रिकॉर्ड करते हैं
    accDescr: Memory मोड इन-मेमोरी सर्कुलर बफ़र में रिकॉर्ड करता है; पुराने इवेंट ओवरराइट होते हैं और केवल नवीनतम रहते हैं, इसलिए प्रतीक्षा के लिए उपयुक्त। File मोड सब कुछ फ़ाइल में रखता है, पर एकमात्र छत खाली डिस्क स्थान है, इसलिए छोटी विश्वसनीय पुनरुत्पादन के लिए उपयुक्त
    ev["ETW इवेंट"] --> ring["Memory मोड: रिंग बफ़र"]
    ev --> filem["File मोड: फ़ाइल बढ़ाएँ"]
    ring -.-> use1["अज्ञात समय की प्रतीक्षा"]
    filem -.-> use2["छोटी विश्वसनीय पुनरुत्पादन"]

चित्र 3: Memory मोड इन-मेमोरी सर्कुलर बफ़र में रिकॉर्ड करता है; पुराने इवेंट ओवरराइट होते हैं और केवल नवीनतम रहते हैं, इसलिए प्रतीक्षा के लिए उपयुक्त। File मोड सब कुछ फ़ाइल में रखता है, पर एकमात्र छत खाली डिस्क स्थान है, इसलिए छोटी विश्वसनीय पुनरुत्पादन के लिए उपयुक्त।

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

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

GUI से कैप्चर के लिए WPRUI शुरू करें, प्रोफ़ाइल और Logging mode चुनें, और Start/Save करें। आधिकारिक How-to प्रक्रिया सारांशित करता है।¹¹ यदि ग्राहक-साइट संपर्क से कैप्चर करवाएँ, ऊपर के तीन कमांड प्रक्रिया में ज्यों के त्यों जा सकते हैं।

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

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

तालिकाओं का सुनहरा नियम — स्तंभ क्रम समूहन तय करता है। WPA तालिका में दो ऊर्ध्वाधर बार हैं, सोना और नीला, और सोने की बार के बाएँ स्तंभ उस क्रम में डेटा को पदानुक्रमित (समूह) करते हैं, और नीली बार के दाएँ स्तंभ योग हैं।¹³ उन्हें Process → Stack रखें तो प्रति-प्रोसेस स्टैक योग मिलता है; Stack → Process रखें तो एक ही स्टैक इस्तेमाल करने वाले हर प्रोसेस का योग — स्तंभ खींचकर क्रम बदलना स्वयं विश्लेषण क्रिया है। यह एक बिंदु समझें तो हर WPA तालिका एक ही तरह पढ़ी जाती है।

flowchart TB
    accTitle: तालिकाओं का सुनहरा नियम — दो बार और स्तंभों की भूमिका
    accDescr: सोने की बार के बाएँ स्तंभ उस क्रम में डेटा पदानुक्रमित करते हैं; सोने और नीली बार के बीच प्रदर्शन स्तंभ हैं; नीली बार के दाएँ स्तंभ योग हैं। स्तंभ खींचकर क्रम बदलना स्वयं विश्लेषण क्रिया है
    left["सोने के बाएँ: समूहन"] --> gold["सोने की बार"]
    gold --> mid["बारों के बीच: प्रदर्शन"]
    mid --> blue["नीली बार"]
    blue --> right["नीले के दाएँ: योग"]
    left -.-> op["विश्लेषण के लिए स्तंभ खींचें"]

चित्र 4: सोने की बार के बाएँ स्तंभ उस क्रम में डेटा पदानुक्रमित करते हैं; सोने और नीली बार के बीच प्रदर्शन स्तंभ हैं; नीली बार के दाएँ स्तंभ योग हैं। स्तंभ खींचकर क्रम बदलना स्वयं विश्लेषण क्रिया है।

समय सीमा संकीर्ण करें। ग्राफ़ पर खींचकर सीमा चुनें, फिर दाएँ-क्लिक और “Zoom”, और योग केवल उस अंतराल पर स्विच होता है। प्रदर्शन जाँच सिद्धांततः हमेशा केवल “वह अंतराल जब समस्या हो रही थी” देखती है (अध्याय 9)।
सिंबल कॉन्फ़िगर करें। स्टैक को फ़ंक्शन नाम से पढ़ने के लिए मेनू से Trace > Load Symbols चलाएँ।¹⁴ डिफ़ॉल्ट पर यह Microsoft के सार्वजनिक सिंबल सर्वर (msdl.microsoft.com) को संदर्भित करता है, इसलिए इंटरनेट हो तो Windows के अपने स्टैक हल हो सकते हैं। अपने ऐप के फ़ंक्शन नाम देखने के लिए Trace > Configure Symbol Paths में अपने ऐप के PDB का फ़ोल्डर जोड़ें।⁸ PDB क्या है, और Release बिल्ड के लिए भी उसे हमेशा क्यों रखें, “PDB (Program Database) क्या है” में सार है। .NET Framework NGen नेटिव इमेज के लिए WPR कैप्चर समय NGen PDB (.ngenpdb) बनाता है और उन्हें ट्रेस के पास फ़ोल्डर में रखता है, और WPA उन्हें स्वतः संदर्भित करता है।⁸ यह केवल NGen इमेज का तंत्र है, और आपका साधारण JIT .NET ऐप कोड दायरे से बाहर है। JIT-कोड पते से फ़ंक्शन नाम का मैपिंग CLR द्वारा छोड़े JIT इवेंट से हल होता है, इसलिए .NET ऐप जाँचते समय CLR प्रदाता (Microsoft-Windows-DotNETRuntime और मिलान Rundown) सक्षम करने वाली रिकॉर्डिंग प्रोफ़ाइल (.wprp) तैयार करें और अध्याय 3 के अपने प्रदाताओं की तरह जोड़ें, wpr -start GeneralProfile -start MyDotNet.wprp!profile-name, ताकि CLR इवेंट ट्रेस में शामिल हों (स्थानीय WPR कौन सी अंतर्निहित प्रोफ़ाइल देता है wpr -profiles से जाँचें)। उसके ऊपर, स्रोत पंक्तियों तक मैपिंग के लिए बिल्ड द्वारा बने PDB रखें, और उन्हें ऊपर के सिंबल पथ में जोड़ें।

flowchart TB
    accTitle: स्टैक को फ़ंक्शन नाम से पढ़ने के लिए सिंबल हल करना
    accDescr: Trace Load Symbols चलाने से Windows स्वयं Microsoft के सार्वजनिक सिंबल सर्वर से हल होता है, और आपका ऐप सिंबल पथ में जोड़े बिल्ड PDB से। NGen इमेज WPR द्वारा बने NGen PDB उपयोग करती हैं; JIT .NET कोड ट्रेस के CLR JIT इवेंट प्लस बिल्ड PDB से हल होता है
    load["Trace > Load Symbols"] --> ms["Windows: सार्वजनिक सिंबल"]
    load --> own["अपना ऐप: बिल्ड PDB"]
    ms -.-> ngen["NGen: WPR .ngenpdb"]
    own -.-> jit["JIT: CLR इवेंट + PDB"]

चित्र 5: Trace Load Symbols चलाने से Windows स्वयं Microsoft के सार्वजनिक सिंबल सर्वर से हल होता है, और आपका ऐप सिंबल पथ में जोड़े बिल्ड PDB से। NGen इमेज WPR द्वारा बने NGen PDB उपयोग करती हैं; JIT .NET कोड ट्रेस के CLR JIT इवेंट प्लस बिल्ड PDB से हल होता है।

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

flowchart TB
    accTitle: लक्षण से WPA ग्राफ़ चुनने की शाखा
    accDescr: समस्या अंतराल पर ज़ूम करें; यदि CPU ऊँची हो तो CPU Usage Sampled पर जाएँ; यदि कम फिर भी धीमा, एकल-कोर / एकल-थ्रेड पिन जाँचें फिर CPU Usage Precise में प्रतीक्षा विश्लेषण; यदि डिस्क संदिग्ध हो, Disk Usage और File IO
    zoom["समस्या अंतराल पर ज़ूम"] --> cpu{"उस अंतराल में CPU"}
    cpu -->|"ऊँची"| sampled["अध्याय 5: Sampled"]
    cpu -->|"कम, फिर भी धीमा"| core{"1-कोर / 1-थ्रेड पिन"}
    core -->|"हाँ"| sampled
    core -->|"नहीं"| precise["अध्याय 6: Precise"]
    cpu -->|"डिस्क संदिग्ध"| disk["अध्याय 7: डिस्क / फ़ाइल I/O"]

चित्र 6: समस्या अंतराल पर ज़ूम करें; यदि CPU ऊँची हो तो CPU Usage Sampled पर जाएँ; यदि कम फिर भी धीमा, एकल-कोर / एकल-थ्रेड पिन जाँचें फिर CPU Usage Precise में प्रतीक्षा विश्लेषण; यदि डिस्क संदिग्ध हो, Disk Usage और File IO।

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

यदि CPU पिन हो, जो देखते हैं वह CPU Usage (Sampled) है। यह सैंपलिंग डेटा है जिसने लगभग हर 1 मिलीसेकंड हर CPU पर रिकॉर्ड किया “अब किस प्रोसेस का कौन सा स्टैक चल रहा है”, और सैंपल संख्या का अनुपात CPU समय का विवरण ज्यों का त्यों है।⁶

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

चित्र 7: लगभग हर 1 मिलीसेकंड हर CPU पर चल रहा स्टैक रिकॉर्ड होता है, और योगित सैंपल अनुपात CPU समय का विवरण है। प्रोसेस से थ्रेड, स्टैक, और फ़ंक्शन पढ़ें। सैंपलों के बीच खत्म हुई छोटी गतिविधि दिखाई नहीं देती।

Graph Explorer के Computation से CPU Usage (Sampled) Analysis टैब पर रखें और Utilization by Process, Stack प्रीसेट चुनें।⁵
Weight (या Count) अवरोही क्रम में प्रोसेस देखें। Task Manager में जो “50%” था उसकी पहचान पहले प्रोसेस स्तर पर स्पष्ट होती है।
अपराधी प्रोसेस के Stack स्तंभ का विस्तार करें। स्टैक वृक्ष के रूप में योगित होते हैं, और उस पथ पर चलना जहाँ शाखा पर संख्या अधिक नहीं गिरती आपको CPU जलाने वाले फ़ंक्शन पर उतारती है। यदि सिंबल हल हों, अपने कोड के किस फ़ंक्शन तक सीधी रेखा है।
यदि वृक्ष फैलाना थकाऊ हो, ग्राफ़ प्रदर्शन Flame पर स्विच करें। चौड़ाई = CPU समय का हिस्सा से खींचा जाता है, इसलिए कौन सा कॉल पथ हावी है एक नज़र में स्पष्ट है। CPU Usage (Sampled) में Flame by Process, Stack प्रीसेट भी है।¹³

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

6. जब CPU कम हो फिर भी धीमा — CPU Usage (Precise) और प्रतीक्षा विश्लेषण

यह लेख का केंद्र है। प्रतीक्षा विश्लेषण पर जाने से पहले एक बात पुष्टि करें। “समग्र CPU उपयोग कम है” का अर्थ “CPU अड़चन नहीं” नहीं है। 16-कोर PC पर एक कोर पर पिन क्रमिक काम (एक UI थ्रेड पूरा दौड़ता) समग्र लगभग 6% ही दिखता है। पहले अध्याय 5 के Sampled (या CPU Usage (Precise) के Utilization by CPU) में जाँचें कि किसी खास कोर या थ्रेड पर पिन नहीं, और यदि नहीं, इस अध्याय पर आएँ — काम चल नहीं पा रहा नहीं, वह प्रतीक्षा कर रहा है। क्या प्रतीक्षा बताता है वह CPU Usage (Precise) है।

जहाँ Sampled सैंपलिंग है, Precise कॉन्टेक्स्ट स्विच (थ्रेड स्विच) का पूर्ण रिकॉर्ड है। थ्रेड प्रतीक्षा में जाता है, किसी ने जगाया (Ready), और CPU पर उतरता है — वह राउंड ट्रिप एक पंक्ति में रहती है, और निम्न स्तंभ पढ़ सकते हैं।⁷⁴

स्तंभ	अर्थ
NewThreadStack	किस स्टैक पर वह थ्रेड प्रतीक्षा में गया (= रुकते समय वह क्या कर रहा था)
Waits (us)	कितनी देर प्रतीक्षा की
Ready (us)	जगाए जाने से CPU पर उतरने तक कितनी देर इंतज़ार कराया गया (CPU विवाद)
ReadyingProcess / ReadyingThreadId	वह प्रोसेस और थ्रेड जिसने उस थ्रेड को जगाया (प्रतीक्षा छोड़ी)
ReadyThreadStack	किस स्टैक पर जगाने वाले ने जगाया

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

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

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

Utilization by Process, Thread प्रीसेट लागू करें और स्तंभों में NewThreadStack व ReadyThreadStack जोड़ें।
पहले वह थ्रेड पहचानें जो विलंबित ऑपरेशन चला रहा था (UI थ्रेड, संबंधित अनुरोध सँभालने वाला थ्रेड)। कुल Waits के अवरोही क्रम में केवल देखना भ्रमित करता है, क्योंकि “जानबूझकर पूरे समय प्रतीक्षा” करने वाले थ्रेड, जैसे मैसेज पंप या टाइमर, शीर्ष पर रहते हैं। लक्ष्य थ्रेड मिलने पर, यदि उसका CPU Usage (ms) बड़ा हो तो अध्याय 5 की CPU समस्या है; यदि Waits हावी हों तो प्रतीक्षा समस्या।
NewThreadStack फैलाएँ और देखें रुकते समय वह क्या कर रहा था। WaitForSingleObject या EnterCriticalSection लॉक प्रतीक्षा है; ReadFile जैसी सिंक्रोनस I/O के अंदर I/O प्रतीक्षा है; सॉकेट रिसीव के अंदर साथी के जवाब की प्रतीक्षा है।
फिर देखें किसने प्रतीक्षा छोड़ी। ReadyThreadStack फैलाएँ और ReadyingProcess / ReadyingThreadId जाँचें। यदि कर्नेल के KiTimerExpiration से जगाया गया तो टाइमर था (= टाइमआउट तक सोया); यदि I/O पूर्णता सँभाल से जगाया गया, वह I/O प्रतीक्षा पुष्टि करता है।⁴
यदि जगाने वाला पक्ष दूसरा थ्रेड या दूसरा प्रोसेस हो, उसी प्रक्रिया से उस थ्रेड की जाँच करें। “A लॉक छोड़ने के लिए B का इंतज़ार कर रहा था, B C की RPC प्रतिक्रिया का, C डिस्क I/O का” — इस श्रृंखला को जड़ तक चलने पर जो मिलता है वह विलंब का क्रिटिकल पाथ है।⁷

flowchart TB
    accTitle: प्रतीक्षा विश्लेषण में चली जाने वाली क्रिटिकल-पाथ श्रृंखला
    accDescr: विलंबित थ्रेड A के NewThreadStack में देखें रुकते समय वह क्या कर रहा था, ReadyThreadStack और ReadyingProcess से जगाने वाला B पहचानें, और B की उसी प्रक्रिया से जड़ डिस्क I/O तक जाँच करें
    a["थ्रेड A（विलंबित काम）"] -->|"लॉक प्रतीक्षा"| b["थ्रेड B（लॉक धारण）"]
    b -->|"RPC प्रतीक्षा"| c["प्रोसेस C"]
    c -->|"सिंक I/O प्रतीक्षा"| d["डिस्क I/O（जड़）"]
    d -.->|"पूर्णता C जगाती है"| c
    c -.->|"प्रतिक्रिया B जगाती है"| b
    b -.->|"लॉक छोड़ना A जगाता है"| a

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

“हमने मल्टीथ्रेड किया और तेज़ नहीं हुआ” जैसे मामले में यह प्रक्रिया हर वर्कर एक ही लॉक पर पंक्तिबद्ध ज्यों का त्यों दिखाती है। डिज़ाइन से लॉक विवाद बचाना “व्यावहारिक मल्टीथ्रेडिंग सर्वोत्तम प्रथाएँ: .NET संस्करण” में है, और सिंक्रोनस I/O में प्रतीक्षा के बजाय पूर्णता सूचना पर चलने वाला Windows तंत्र “I/O Completion Ports (IOCP) और .NET Thread Pool” में है। WPA में “किसका इंतज़ार था” पिन कर उन डिज़ाइन तर्कों से ठीक करना एक सतत प्रवाह है।

7. डिस्क और फ़ाइल I/O — “कोई डिस्क स्कैन कर रहा है” पहचानना

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

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

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

एंटीवायरस हर फ़ाइल स्कैन कर रहा था। जिस खिड़की में ऐप स्टार्ट होने में धीमा था, एंटीवायरस प्रोसेस बड़ी मात्रा में रीड जारी करता दिखता है। प्रोसेस नाम, पथ, और मात्रा बहिष्करण चर्चा के लिए साक्ष्य ज्यों के त्यों हैं।
दूसरा प्रोसेस भारी लिख रहा था। बैकअप, इंडेक्सर, बहुत अधिक लिखे लॉग, आदि। लेखन डिस्क तक कब पहुँचता है इसमें कैश मैनेजर शामिल है, इसलिए “जिस क्षण आपने लिखा” और “जिस क्षण डिस्क व्यस्त है” का विचलन भी “Cache Manager — आपका WriteFile वास्तव में डिस्क तक कब पहुँचता है” में है।

File I/O एक परत ऊपर है, ऐप द्वारा जारी फ़ाइल ऑपरेशन (Create/Read/Write आदि) का रिकॉर्ड, और Duration by Process, Thread, Type जैसे प्रीसेट प्रति फ़ाइल नाम और प्रति ऑपरेशन समय योग कर सकते हैं।¹⁵ वह मामला जो फ़ाइल सिस्टम या फ़िल्टर ड्राइवर में डिस्क तक पहुँचने से पहले समय खर्च करता है Disk Usage में नहीं आता, इसलिए बेमेल स्वयं — “Disk Usage शांत है पर File I/O धीमा” — सुराग है। यदि सिंक्रोनस और असिंक्रोनस I/O की यांत्रिकी से शुरू करना चाहें, “सिंक्रोनस और असिंक्रोनस I/O — OVERLAPPED वास्तव में क्या मतलब है” देखें।

flowchart TB
    accTitle: File IO और Disk Usage जो अलग परतें देखते हैं
    accDescr: ऐप का फ़ाइल ऑपरेशन फ़ाइल सिस्टम और फ़िल्टर ड्राइवर से OS I/O कतार होते डिस्क डिवाइस तक जाता है। File IO ऊपरी परत पर ऑपरेशन रिकॉर्ड करता है; Disk Usage डिस्क तक पहुँची I/O; IO Time और Disk Service Time का अंतर कतार समय है
    app["ऐप: ReadFile / WriteFile"] --> fio["FS और फ़िल्टर（File I/O）"]
    fio --> queue["OS I/O कतार"]
    queue --> dev["डिस्क डिवाइस（Disk Usage）"]
    fio -.-> n1["Disk Usage से छूटा"]
    queue -.-> n2["IO Time − Service Time"]
    dev -.-> n3["Service Time = डिवाइस"]

चित्र 10: ऐप का फ़ाइल ऑपरेशन फ़ाइल सिस्टम और फ़िल्टर ड्राइवर से OS I/O कतार होते डिस्क डिवाइस तक जाता है। File IO ऊपरी परत पर ऑपरेशन रिकॉर्ड करता है; Disk Usage डिस्क तक पहुँची I/O; IO Time और Disk Service Time का अंतर कतार समय है।

“शायद मेमोरी कम है और स्वैप हो रहा है” की सोच Task Manager और Resource Monitor में पहले अलगाव पा सकती है, WPA पर जाने से पहले। पर कमिटेड मेमोरी अकेले से न खारिज करें — कमिट जगह होने पर भी भौतिक-मेमोरी दबाव वर्किंग सेट काट सकता है और हार्ड फॉल्ट जारी रह सकते हैं। उपलब्ध भौतिक मेमोरी और Resource Monitor के “Hard Faults/sec” भी जाँचें। उन्हें कैसे पढ़ें “Windows का "मेमोरी उपयोग" वास्तव में क्या मतलब है” में है।

8. धीमा बूट और लॉगऑन — बूट ट्रेस का प्रवेश

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

:: 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: बूट-ट्रेस प्रवाह
    accDescr: addboot से अगले बूट पर स्वचालित रिकॉर्डिंग व्यवस्था कर रीस्टार्ट के बाद OS बूट पर स्वतः रिकॉर्ड करता है। लॉगऑन बाद stopboot से सहेजना व्यवस्था भी साफ़ करता है। त्यागने के लिए cancelboot से साफ़ करें
    add["wpr -boottrace -addboot"] --> rebootpc["रीस्टार्ट（धीमा बूट）"]
    rebootpc --> auto["OS बूट पर रिकॉर्ड करता है"]
    auto --> stop2["लॉगऑन बाद: -stopboot"]
    add -.-> cancel["त्यागें: -cancelboot"]

चित्र 11: addboot से अगले बूट पर स्वचालित रिकॉर्डिंग व्यवस्था कर रीस्टार्ट के बाद OS बूट पर स्वतः रिकॉर्ड करता है। लॉगऑन बाद stopboot से सहेजना व्यवस्था भी साफ़ करता है। त्यागने के लिए cancelboot से साफ़ करें।

बूट और शटडाउन माप जो पहले xbootmgr के पास था वर्तमान WPR में -onoffscenario Boot जैसे विकल्प से भी चल सकता है।³ कैप्चर ट्रेस पिछले अध्यायों के समान टूलकिट से पढ़ा जाता है। Processes ग्राफ़ में टाइमलाइन पर कौन सा प्रोसेस कब जन्मा देखें, जहाँ बूट अटका उस खिड़की पर ज़ूम करें, और CPU, प्रतीक्षा, या डिस्क वर्गीकृत करें — श्रृंखला में किसी चीज़ का इंतज़ार करता स्टार्टअप ऐप, खास I/O पर अटकी सेवा स्टार्ट, आदि दिखने लगते हैं। बूट विश्लेषण अपने आप में गहरा विशेषज्ञता क्षेत्र है, इसलिए यह लेख केवल प्रवेश तक जाता है: “हाथ से न पकड़ी जा सकने वाली समस्या भी WPR से कैप्चर हो सकती है”। GeneralProfile बूट ट्रेस से समग्र चित्र पकड़कर शुरू करें।

9. कार्य पैटर्न — वर्गीकृत → ज़ूम → स्टैक, दोहराया

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

घटना का समय पिन करें। “धीमा था” नहीं, बल्कि “10:23:40–10:24:10 धीमा था”। ऐप लॉग, इवेंट लॉग, ऑपरेटर का नोट — कुछ भी चलेगा। यदि आपका ऐप चेकपॉइंट ETW या इवेंट लॉग में लिखता है, ट्रेस के अंदर इवेंट ज्यों के त्यों समय के खूँटे बन जाते हैं।
केवल उस अंतराल पर ज़ूम करें। पूरे ट्रेस का योग औसत हो जाता है, और महत्त्वपूर्ण विसंगति पतली पड़ती है। WPA विश्लेषण हमेशा “असामान्य अंतराल” बनाम “सामान्य अंतराल” की तुलना है।
पहले “CPU, प्रतीक्षा, या I/O” वर्गीकृत करें। CPU Usage (Sampled) देखें; यदि जल रहा हो, अध्याय 5। यदि नहीं जल रहा, CPU Usage (Precise) के Waits (अध्याय 6)। यदि Disk Usage IO Time फूला हो, अध्याय 7। यह तीन-तरफ़ा काँटा पहले लेने से भटकते नहीं।
परिकल्पना → ज़ूम → स्टैक दोहराएँ। यदि सोचें “एंटीवायरस?”, उस प्रोसेस तक संकीर्ण करें और स्टैक से पुष्टि करें। यदि न टिके, अगली परिकल्पना। स्टैक तक चलकर पुष्टि किए बिना निष्कर्ष न निकालना इस तरह की जाँच का अनुशासन है।

flowchart TB
    accTitle: प्रदर्शन जाँच का पुनरावृत्तीय लूप
    accDescr: घटना का समय पिन करें, अंतराल पर ज़ूम करें, CPU / प्रतीक्षा / I/O वर्गीकृत करें, परिकल्पना बनाकर संकीर्ण करें, और स्टैक से पुष्टि करें। यदि टिके, कारण पुष्ट; यदि नहीं, अगली परिकल्पना से दोहराएँ
    time["समय पिन करें"] --> zoomstep["उस अंतराल पर ज़ूम"]
    zoomstep --> triage["CPU / प्रतीक्षा / I/O वर्गीकृत करें"]
    triage --> hypo["परिकल्पना और संकीर्ण"]
    hypo --> stack["स्टैक से पुष्टि"]
    stack -->|"टिकती है"| fix["कारण पुष्ट"]
    stack -->|"नहीं"| hypo

चित्र 12: घटना का समय पिन करें, अंतराल पर ज़ूम करें, CPU / प्रतीक्षा / I/O वर्गीकृत करें, परिकल्पना बनाकर संकीर्ण करें, और स्टैक से पुष्टि करें। यदि टिके, कारण पुष्ट; यदि नहीं, अगली परिकल्पना से दोहराएँ।

अंत में, कैप्चर फ़ाइल का सँभाल। ETL फ़ाइल सिस्टम के अंदर को व्यापक रूप से प्रतिबिंबित करती है: हर प्रोसेस के नाम, खुली फ़ाइलों के पथ, लोड मॉड्यूल, और (प्रोफ़ाइल के अनुसार) रजिस्ट्री कुंजी नाम। मानक GeneralProfile कैप्चर में संचार सामग्री जैसे डेटा शरीर शामिल नहीं, पर यदि कस्टम प्रदाता सक्षम किया, उस इवेंट का पेलोड (ऐप द्वारा रिकॉर्ड स्ट्रिंग आदि) ज्यों का त्यों जाता है। जो प्रदाता सक्षम किए वे क्या छोड़ते हैं पुष्टि कर, इसे कंपनी से बाहर जाने लायक गोपनीय फ़ाइल मानें। पैकेट कैप्चर की तरह न्यूनतम आवश्यक कैप्चर, प्राप्तकर्ता से सहमति, और प्रतिधारण अवधि व विलोपन प्रक्रिया में शामिल करें।

flowchart TB
    accTitle: ETL फ़ाइल क्या प्रतिबिंबित करती है, और कैसे सँभालें
    accDescr: ETL हर प्रोसेस नाम, खुली फ़ाइलों के पथ, मॉड्यूल, और प्रोफ़ाइल के अनुसार रजिस्ट्री कुंजी नाम प्रतिबिंबित करता है; कस्टम प्रदाता सक्षम करने से उसका पेलोड भी शामिल। गोपनीय मानें: न्यूनतम आवश्यक कैप्चर, दूसरे पक्ष से सहमति, और प्रतिधारण अवधि व विलोपन
    etl["ETL फ़ाइल"] --> a1["नाम, पथ, मॉड्यूल"]
    a1 --> a2["रजिस्ट्री कुंजियाँ（कुछ）"]
    a2 --> a3["कस्टम पेलोड"]
    a3 -.-> rule["गोपनीय मानें"]

चित्र 13: ETL हर प्रोसेस नाम, खुली फ़ाइलों के पथ, मॉड्यूल, और प्रोफ़ाइल के अनुसार रजिस्ट्री कुंजी नाम प्रतिबिंबित करता है; कस्टम प्रदाता सक्षम करने से उसका पेलोड भी शामिल। गोपनीय मानें: न्यूनतम आवश्यक कैप्चर, दूसरे पक्ष से सहमति, और प्रतिधारण अवधि व विलोपन।

10. सारांश

Task Manager जो “पूरा PC धीमा” नहीं समझा सकता, OS-व्यापी ETW ट्रेस से जाँचा जाता है — WPR से कैप्चर, WPA से पढ़ें। wpr.exe Windows 8.1 और बाद में साथ आता है, इसलिए ग्राहक वातावरण में कैप्चर, ETL घर ले जाना, और अपने मशीन पर WPA में पढ़ना लागू रहता है।
कैप्चर तीन कदम है wpr -start GeneralProfile -filemode → दोहराएँ → wpr -stop trace.etl। यदि दोहरा सकते हैं, कुछ मिनटों में File मोड; यदि प्रतीक्षा, Memory मोड (रिंग बफ़र)। लंबा बेहतर नहीं।
WPA तीन बिंदु लेते ही शुरू हो सकता है: तालिकाओं का सुनहरा नियम (सोने की बार के बाएँ = समूहन), समय सीमा ज़ूम, और सिंबल कॉन्फ़िगरेशन (अपने ऐप को PDB चाहिए)।
यदि CPU ऊँची हो, CPU Usage (Sampled) में प्रोसेस → स्टैक → फ़ंक्शन चलें। यदि CPU कम फिर भी धीमा, CPU Usage (Precise) में श्रृंखला NewThreadStack (रुकते समय क्या कर रहा था) → Waits (कितनी देर प्रतीक्षा) → ReadyingProcess और ReadyThreadStack (किसने जगाया) जड़ तक चलें।
डिस्क के लिए Disk Usage IO Time और Service Time के अंतर से “कतार में बिताया समय” देखें, और कारण (डिवाइस स्वयं धीमा, या किसने कतार बनाई) Service Time तथा प्रोसेस, पथ, स्टैक विवरण से पहचानें। धीमा बूट wpr -boottrace से कैप्चर हो सकता है।
कार्य पैटर्न है (1) समय पिन करें (2) अंतराल पर ज़ूम (3) CPU, प्रतीक्षा, या I/O वर्गीकृत करें (4) परिकल्पना → ज़ूम → स्टैक दोहराएँ। ETL को गोपनीय मानें क्योंकि उसमें आंतरिक जानकारी है।

WPA की स्क्रीन डराती है, और पहले घंटे में सब भटकते हैं। जब दो रीढ़ — “सोने की बार के बाएँ समूहन है” और “Sampled जहाँ जला, Precise किसका इंतज़ार” — बैठ जाएँ, बाकी वही क्रिया दोहराई जाती है। अगली बार जब परामर्श आए कि “CPU में जगह है फिर भी धीमा”, Task Manager बंद करें और ट्रेस कैप्चर करें।

संदर्भ लिंक

Microsoft Learn, Introduction to WPR. कि WPR ETW-आधारित प्रदर्शन रिकॉर्डिंग टूल है; कि कमांड-लाइन संस्करण WPR.exe Windows 8.1 और बाद में बिना अतिरिक्त इंस्टॉल साथ आता है; GUI संस्करण WPRUI.exe से संबंध; और रिकॉर्डिंग प्रोफ़ाइल का विचार। ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Windows Performance Analyzer. कि WPA Windows ADK में शामिल है, WPR, Xperf आदि द्वारा रिकॉर्ड ETW इवेंट से ग्राफ़ और डेटा तालिकाएँ बनाने वाला विश्लेषण टूल है, और कोई भी ETL फ़ाइल खोलकर विश्लेषित कर सकता है। ↩ ↩² ↩³ ↩⁴
Microsoft Learn, WPR Command-Line Options. wpr -start/-stop/-cancel/-status/-profiles का सिंटैक्स; -filemode (डिफ़ॉल्ट मेमोरी मोड है); एक साथ कई प्रोफ़ाइल निर्दिष्ट करना; -boottrace से बूट ट्रेस (addboot/stopboot/cancelboot); और -onoffscenario से Boot जैसे On/Off संक्रमण रिकॉर्ड करना। ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, CPU Analysis. CPU Usage (Precise) ग्राफ़ स्तंभों की परिभाषाएँ (NewThreadStack, ReadyThreadStack, ReadyingProcess, Waits, आदि); ReadyThreadStack फैलाकर ReadyingProcess/ReadyingThread को प्रतीक्षा के मूल कारण तक चलने की प्रक्रिया; और KiTimerExpiration (टाइमर प्रतीक्षा) या I/O पूर्णता से जाग पहचानना। ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Troubleshoot processes and threads by using WPR and WPA. ऊँचे CPU उपयोग पर CPU Usage (Sampled) को Process→Stack पढ़ने, और प्रतीक्षा विश्लेषण में CPU Usage (Precise) Readying Process, Readying Thread, Readying Stack, तथा Wait स्तंभ उपयोग जैसी कॉन्फ़िगरेशन; और लक्षण अनुसार प्रोफ़ाइल व ग्राफ़ की संगतता तालिका। ↩ ↩²
Microsoft Learn, Exercise 2 - Evaluate Fast Startup Using Windows Performance Toolkit. कि CPU Usage (Sampled) लगभग 1-मिलीसेकंड अंतराल पर सैंपलिंग है और सैंपलों के बीच छोटी गतिविधि रिकॉर्ड नहीं होती; प्रोसेस → थ्रेड → स्टैक चलकर CPU खपत का विवरण पहचानने की प्रक्रिया; और Disk Usage IO Time (कतार समय सहित) तथा Disk Service Time (डिस्क प्रसंस्करण समय) का अर्थ। ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Exercise 3 - Understand Critical Path and Wait Analysis. क्रिटिकल-पाथ विश्लेषण का विचार (Running / Ready / Waiting वर्गीकरण); CPU Usage (Precise) तालिका स्तंभ NewThreadStack, ReadyThreadStack, ReadyingProcess, Waits, Ready आदि का अर्थ; और जगाने वाले थ्रेड को बारी-बारी चलकर विलंब श्रृंखला सुलझाने की प्रक्रिया। ↩ ↩² ↩³
Microsoft Learn, Loading Symbols. कि _NT_SYMBOL_PATH अनसेट होने पर WPA डिफ़ॉल्ट पर Microsoft के सार्वजनिक सिंबल सर्वर (msdl.microsoft.com) को संदर्भित करता है; अपने घटकों के लिए PDB पथ जोड़ना; और कि WPR .NET managed सिंबल के लिए ट्रेस के पास .ngenpdb फ़ोल्डर में PDB बनाता है और WPA उन्हें स्वतः संदर्भित करता है। ↩ ↩² ↩³
Microsoft Learn, Built-in Recording Profiles. WPR में अंतर्निहित रिकॉर्डिंग प्रोफ़ाइल की सूची (CPU उपयोग, Disk I/O गतिविधि, File I/O गतिविधि, Registry I/O गतिविधि, Networking I/O गतिविधि, और अन्य) और प्रत्येक प्रोफ़ाइल क्या रिकॉर्ड करती है। ↩
Microsoft Learn, Logging Mode. कि रिकॉर्डिंग मोड File (सतत फ़ाइल) और Memory (इन-मेमोरी सर्कुलर बफ़र) हैं और डिफ़ॉल्ट Memory है; कि Memory अज्ञात समय की समस्या के लिए उपयुक्त है और पुराने इवेंट ओवरराइट होते हैं; और कि File की एकमात्र छत खाली डिस्क स्थान है और बहुत बड़ी फ़ाइल WPA में विश्लेषण-अयोग्य हो सकती है। ↩ ↩²
Microsoft Learn, WPR How-to Topics. WPRUI में रिकॉर्डिंग शुरू और रोकने की प्रक्रिया; प्रोफ़ाइल, विवरण स्तर, और Logging mode चुनना; और सावधानी कि लंबी रिकॉर्डिंग फ़ाइल विशाल और WPA में विश्लेषण-अयोग्य बना सकती है, इसलिए Memory मोड चुनना चाहिए। ↩ ↩²
Microsoft Learn, Graph Explorer. कि Graph Explorer विंडो System Activity, Computation, Storage, और Memory जैसी श्रेणियों में ग्राफ़ थंबनेल सूचीबद्ध करती है; और कि ग्राफ़ को Analysis टैब पर खींचकर तालिका के साथ दिखाते हैं। ↩
Microsoft Learn, Graphs (WPA Features). WPA का Flame ग्राफ़ प्रदर्शन; तालिका संरचना जिसमें सोने की बार के बाएँ स्तंभ समूहन हैं और नीली बार के दाएँ स्तंभ योग हैं; और CPU Usage (Sampled) Flame by Process, Stack प्रीसेट। ↩ ↩²
Microsoft Learn, Load Symbols or Configure Symbol Paths. WPA के Trace मेनू से Load Symbols से सिंबल लोड करना; और Configure Symbol Paths संवाद में सिंबल पथ सेट व बदलने की प्रक्रिया। ↩
Microsoft Learn, List of WPA Graphs. WPA में उपलब्ध ग्राफ़ की सूची। Disk Usage प्रीसेट जैसे IO Time by Process, IO Type; Service Time by Process, Path Name, Stack; Utilization by Process, Path Name, Stack; और File I/O प्रीसेट जैसे Duration by Process, Thread, Type। ↩ ↩² ↩³

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

स्लीप से रिज़्यूम पर टूटने वाले ऐप — Windows पावर इवेंट कैसे काम करते हैं और उनसे बचने वाले व्यावसायिक ऐप कैसे बनाएँ

लैपटॉप खोला और व्यावसायिक ऐप के कनेक्शन मर चुके थे — कारण वह डिज़ाइन है जिसने स्लीप का हिसाब ही नहीं रखा। यह लेख WM_POWERBROADCAST सूचना ...

लेख पढ़ें

DllMain और Loader Lock — DLL आरंभीकरण में "कुछ न करें" कहे जाने का वास्तविक कारण

DllMain से LoadLibrary क्यों न बुलाएँ या दूसरे थ्रेड से सिंक्रोनाइज़ न करें। प्राथमिक स्रोतों से यह लेख समझाता है कि लोडर लॉक हर DLL सूचन...

लेख पढ़ें

"Not Responding" वास्तव में क्या है — Windows ऐप के हैंग का निर्णय कैसे करता है, और न हैंग करने वाले ऐप कैसे डिज़ाइन करें

Windows का "Not Responding" वह तंत्र है जिसमें OS तय करता है कि विंडो ने 5 सेकंड संदेश नहीं लिया और उसे घोस्ट विंडो से बदल देता है। यह ले...

लेख पढ़ें

Win32 Thread Pool API — CreateThreadpoolWork से थ्रेड बनाए बिना समवर्तिता

क्या आपके नेटिव कोड में CreateThread कॉल बिखरी पड़ी हैं? यह लेख Vista में पुनर्डिज़ाइन की गई Win32 थ्रेड पूल API — work, timer, wait और i...

लेख पढ़ें

Named Pipes व्यवहार में — डिज़ाइन से सुरक्षा तक, Windows की मानक IPC

Named pipes — Windows की मानक इंटर-प्रोसेस कम्युनिकेशन — की व्यावहारिक मार्गदर्शिका। यह लेख प्राथमिक स्रोतों से बाइट और मैसेज मोड का चुना...

लेख पढ़ें

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

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

Windows ऐप विकास

व्यावसायिक ऐप, डिवाइस एकीकरण और संचार उपकरण, आवश्यकताओं से विकास तक।

सेवा देखें संपर्क करें

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

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

WPR और WPA कहाँ से मिलते हैं? क्या उन्हें उस ग्राहक वातावरण में इस्तेमाल कर सकते हैं जहाँ सॉफ़्टवेयर इंस्टॉल नहीं हो सकता?: कैप्चर टूल wpr.exe (कमांड-लाइन संस्करण) Windows 8.1 और बाद में साथ आता है, इसलिए बिना अतिरिक्त इंस्टॉल के उपयोग हो सकता है। GUI संस्करण WPRUI और विश्लेषण टूल WPA (Windows Performance Analyzer) Windows ADK (Windows Assessment and Deployment Kit) में शामिल हैं और अलग इंस्टॉल चाहिए। व्यवहार में, यदि काम बाँटें "ग्राहक वातावरण में केवल OS-मानक wpr.exe से ETL फ़ाइल कैप्चर करें, घर ले जाएँ, और अपने मशीन पर WPA में विश्लेषण करें", तो उस साइट पर भी सिस्टम-व्यापी प्रदर्शन जाँच हो सकती है जहाँ सॉफ़्टवेयर नहीं जोड़ सकते।
Task Manager में CPU बचा दिखे तो भी धीमा क्यों? WPA में क्या दिखता है?: जब CPU उपयोग कम हो और फिर भी धीमा हो, काम CPU इस्तेमाल नहीं कर पा रहा नहीं — वह "किसी चीज़ का इंतज़ार" कर रुका है। लॉक विवाद, सिंक्रोनस I/O पूरा होने की प्रतीक्षा, और दूसरे प्रोसेस के जवाब की प्रतीक्षा विशिष्ट हैं। Task Manager केवल परिणाम, उपयोग, दिखाता है; WPA का CPU Usage (Precise) प्रति-कॉन्टेक्स्ट-स्विच रिकॉर्ड से दिखाता है कि थ्रेड कहाँ इंतज़ार शुरू हुआ (NewThreadStack), कितनी देर इंतज़ार किया (Waits), और किसने जगाया (ReadyingProcess, ReadyThreadStack)। जिस पक्ष ने इंतज़ार कराया उसका पीछा कर "धीमेपन का अपराधी" फ़ंक्शन तक पहचान सकते हैं।
ट्रेस कितनी देर कैप्चर करें? फ़ाइल बहुत बड़ी तो नहीं हो जाएगी?: यदि समस्या दोहरा सकते हैं, आधार है पुनरुत्पादन से ठीक पहले शुरू करें, ठीक बाद रोकें, और कुछ मिनटों में रखें। WPR का डिफ़ॉल्ट Memory मोड है, जो इन-मेमोरी सर्कुलर बफ़र में रिकॉर्ड करता है; पुराने इवेंट ओवरराइट होते हैं, इसलिए अज्ञात समय की समस्या का इंतज़ार करने के लिए उपयुक्त है। File मोड, -filemode के साथ, सब कुछ सतत फ़ाइल में रखता है, पर एकमात्र छत खाली डिस्क स्थान है, और बहुत बड़ी फ़ाइल WPA में विश्लेषण-अयोग्य हो सकती है। लंबी प्रतीक्षा के लिए Memory मोड, छोटी विश्वसनीय पुनरुत्पादन के लिए File मोड।
PerfView और WPA में कैसे चुनें?: दोनों टूल ETW ट्रेस सँभालते हैं, पर ताकत अलग है। PerfView .NET रनटाइम को गहराई से समझता है और GC, आवंटन, JIT जैसी managed-ऐप जाँच में मज़बूत है। WPA OS-व्यापी CPU, डिस्क, फ़ाइल I/O, पावर आदि को ग्राफ़ और तालिकाओं में पढ़ने के लिए उपयुक्त है, और पहला विकल्प है जब "कोई खास ऐप नहीं बल्कि पूरा PC धीमा है", "कई प्रोसेस शामिल हैं", या "ऐप के बाहर कुछ (एंटीवायरस, ड्राइवर, दूसरा प्रोसेस) संदिग्ध है"। अंगूठे का नियम: अकेले अपने .NET ऐप की सुस्ती के लिए PerfView, पूरे सिस्टम की सुस्ती के लिए WPR/WPA।
क्या ग्राहक के प्रोडक्शन वातावरण में WPR चलाना ठीक है?: छोटी कैप्चर व्यवहार में आम है, पर बिना शर्त सुरक्षित नहीं। ETW हल्का है, पर स्टैक सहित बड़ी मात्रा में इवेंट रिकॉर्ड करने से निश्चित CPU और मेमोरी खर्च होता है। पुनरुत्पादन चरण से ठीक पहले शुरू और ठीक बाद रोकना, कैप्चर कुछ मिनटों में रखना, और कम व्यावसायिक प्रभाव वाले समय चलाना — इन्हें किसी सामान्य परिवर्तन जैसी ही स्वीकृति प्रक्रिया में शामिल करें। साथ ही, ETL फ़ाइल में प्रोसेस नाम, फ़ाइल पथ, एक्ज़ीक्यूटेबल जानकारी जैसी आंतरिक सिस्टम जानकारी होती है, इसलिए कंपनी से बाहर जाने पर कैसे सँभाला जाएगा (न्यूनतमकरण, प्रतिधारण अवधि, विलोपन) पहले तय करें।

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

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

Go Komura

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

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

प्रोफ़ाइल देखें संपर्क करें

सार्वजनिक लिंक

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ब्लॉग पर लौटें

WPR/WPA व्यवहार में — "पूरा PC धीमा है" की सिस्टम-व्यापी प्रदर्शन जाँच का परिचय

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

2. टूल कहाँ बैठते हैं — WPR कैप्चर करता है, WPA पढ़ता है

3. व्यवहार में कैप्चर (WPR) — start, दोहराएँ, stop

3.1. Memory मोड और File मोड — क्या दोहरा सकते हैं, या प्रतीक्षा करते हैं

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

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

6. जब CPU कम हो फिर भी धीमा — CPU Usage (Precise) और प्रतीक्षा विश्लेषण

7. डिस्क और फ़ाइल I/O — “कोई डिस्क स्कैन कर रहा है” पहचानना

8. धीमा बूट और लॉगऑन — बूट ट्रेस का प्रवेश

9. कार्य पैटर्न — वर्गीकृत → ज़ूम → स्टैक, दोहराया

10. सारांश

संबंधित लेख

संबंधित परामर्श क्षेत्र

संदर्भ लिंक

स्लीप से रिज़्यूम पर टूटने वाले ऐप — Windows पावर इवेंट कैसे काम करते हैं और उनसे बचने वाले व्यावसायिक ऐप कैसे बनाएँ

DllMain और Loader Lock — DLL आरंभीकरण में "कुछ न करें" कहे जाने का वास्तविक कारण

"Not Responding" वास्तव में क्या है — Windows ऐप के हैंग का निर्णय कैसे करता है, और न हैंग करने वाले ऐप कैसे डिज़ाइन करें

Win32 Thread Pool API — CreateThreadpoolWork से थ्रेड बनाए बिना समवर्तिता

Named Pipes व्यवहार में — डिज़ाइन से सुरक्षा तक, Windows की मानक IPC

संबंधित विषय

Windows के तकनीकी विषय

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

Windows ऐप विकास

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

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

Go Komura