ਸਿੱਖੋ ਕਿ Mark Russinovich ਦੀ Windows Internals ਸੋਚ ਨੇ Sysinternals, WinDbg ਵਰਕਫਲੋਜ਼ ਅਤੇ Windows 'ਤੇ ਡਿਬੱਗਿੰਗ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਪ੍ਰਾਯੋਗਿਕ ਨਿਰੀਖਣਯੋਗਤਾ ਨੂੰ ਕਿਵੇਂ ਆਕਾਰ ਦਿੱਤਾ।
ਜੇ ਤੁਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ Windows ਚਲਾਉਂਦੇ ਹੋ—ਲੈਪਟਾਪ, ਸਰਵਰ, VDI ਜਾਂ ਕਲਾਉਡ VM—ਤਾਂ Mark Russinovich ਦਾ ਕੰਮ ਰੋਜ਼ਮਰਰਾ ਦੀ ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਅਜੇ ਵੀ Nazਰ ਆਉਂਦਾ ਹੈ। ਇਹ ਨੋਸਟੈਲਜੀਆ ਜਾਂ ਸ਼ਖਸੀਅਤ ਕਰਕੇ ਨਹੀਂ, ਸਗੋਂ ਇਸ ਲਈ ਕਿ ਉਸਨੇ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਲਈ ਇੱਕ ਸਬੂਤ-ਪਹਿਲਾਂ ਪਹੁੰਚ ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਬਣਾਇਆ: ਦੇਖੋ ਕਿ OS ਅਸਲ ਵਿੱਚ ਕੀ ਕਰ ਰਿਹਾ ਹੈ, ਫਿਰ ਲੱਖਣਾਂ ਨੂੰ ਸਬੂਤ ਨਾਲ ਸਮਝਾਓ।
ਨਿਰੀਖਣਯੋਗਤਾ ਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਸਿਸਟਮ ਦੇ ਉਤਪੰਨ ਸੰਕੇਤਾਂ (ਇਵੈਂਟ, ਟਰੇਸ, ਕਾਉਂਟਰ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ “ਹੁਣ ਕੀ ਹੋ ਰਿਹਾ ਹੈ?” ਦਾ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ। ਜਦੋਂ ਕੋਈ ਸਰਵਿਸ ਧੀਮੀ ਹੋ ਜਾਂਦੀ ਹੈ ਜਾਂ ਲੋਗਿਨ ਟੰਗ ਹੁੰਦੇ ਹਨ, ਨਿਰੀਖਣਯੋਗਤਾ ਅਨੁਮਾਨ ਤੇ ਗਿਆਨ ਵਿੱਚ ਫ਼ਰਕ ਬਣਾਉਂਦੀ ਹੈ।
ਡਿਬੱਗਿੰਗ ਅਸਪਸ਼ਟ ਸਮੱਸਿਆ (“ਇਹ ਫ੍ਰੀਜ਼ ਹੋ ਗਿਆ”) ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਮਕੈਨਿਜ਼ਮ ਵਿੱਚ ਬਦਲਨਾ ਹੈ (“ਇਹ ਥ੍ਰੈਡ I/O 'ਤੇ ਬਲਾਕ ਹੋਇਆ ਹੈ”, “ਇਹ ਪ੍ਰੋਸੈਸ ਪੇਜ ਫ਼ਾਇਲ ਤੇ ਥਰੈਸ਼ ਕਰ ਰਿਹਾ ਹੈ”, “ਇਸ DLL ਇੰਜੈਕਸ਼ਨ ਨੇ ਵਿਹਾਰ ਬਦਲ ਦਿੱਤਾ”)।
ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਿਸਟਮ ਤਣਾਅ ਹੇਠ ਕੰਮ ਜਾਰੀ ਰੱਖ ਸਕੇ ਅਤੇ ਪੂਰਨ ਤਰੀਕੇ ਨਾਲ ਮੁੜ ਉੱਠ ਸਕੇ—ਘੱਟ ਘਟਨਾਵਾਂ, ਤੇਜ਼ ਰੀਸਟੋਰ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਬਦਲਾਅ।
ਅਧਿਕਤਰ “ਰਹਸਮਈ ਬਹਿਰਾਜ਼” ਅਸਲ ਵਿੱਚ ਰਹਸਮਈ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ Windows ਦੇ ਉਹ ਵਿਹਾਰ ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਅਜੇ ਤੱਕ ਮੈਪ ਨਹੀਂ ਕੀਤੇ: ਹੈਂਡਲ ਲੀਕ, ਬੇਹਦ ਚਲਦੇ ਬੱਚੇ ਪ੍ਰੋਸੈਸ, ਅਟਕੇ ਡਰਾਈਵਰ, DNS ਟਾਈਮਆਊਟ, ਟੁੱਟੇ ਆਟੋ-ਸਟਾਰਟ ਐਂਟ੍ਰੀ, ਜਾਂ ਸਿਕਿਊਰਟੀ ਟੂਲਿੰਗ ਜੋ ਓਵਰਹੈੱਡ ਜੋੜਦਾ ਹੈ। Windows internals (ਪ੍ਰੋਸੈਸ, ਥ੍ਰੈਡ, ਹੈਂਡਲ, ਸਰਵਿਸ, ਮੈਮੋਰੀ, I/O) ਦੀ ਬੁਨਿਆਦੀ ਸਮਝ ਤੁਹਾਨੂੰ ਨਮੂਨੇ ਤੇਜ਼ੀ ਨਾਲ ਪਛਾਣਨ ਅਤੇ ਮੁੱਦੇ ਗੁੰਮ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸਹੀ ਸਬੂਤ ਇਕੱਤਰ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
ਅਸੀਂ ਅਮਲ-ਮੁਖੀ, ਓਪਰੇਸ਼ਨ-ਮਿੱਤ੍ਰ ਵਰਕਫਲੋਜ਼ 'ਤੇ ਧਿਆਨ ਦਿਆਂਗੇ ਜੋ ਵਰਤਦੇ ਹਨ:
ਲਕੜੀ ਦਾ ਮਕਸਦ ਤੁਹਾਨੂੰ ਕਰਨਲ ਇੰਜੀਨੀਅਰ ਬਣਾਉਣਾ ਨਹੀਂ—ਇਹ ਹੈ Windows ਇੰਸਿਡੈਂਟਾਂ ਨੂੰ ਛੋਟਾ, ਸ਼ਾਂਤ ਅਤੇ ਆਸਾਨ ਸਮਝਣਯੋਗ ਬਣਾਉਣਾ ਤਾਂ ਜੋ ਫਿਕਸ ਸੁਰੱਖਿਅਤ ਅਤੇ ਦੋਹਰਾਏ ਜਾ ਸਕਣ।
Windows “internals” ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਉਹ ਮਕੈਨਿਜ਼ਮ ਹਨ ਜੋ Windows ਅਸਲ ਕੰਮ ਕਰਨ ਲਈ ਵਰਤਦਾ ਹੈ: ਥ੍ਰੈਡਾਂ ਦੀ ਸ਼ੈਡਿਊਲਿੰਗ, ਮੈਮੋਰੀ ਦਾ ਪ੍ਰਬੰਧ, ਸਰਵਿਸਾਂ ਦੀ ਸ਼ੁਰੂਆਤ, ਡਰਾਈਵਰ ਲੋਡ ਕਰਨਾ, ਫ਼ਾਇਲ ਅਤੇ ਰਜਿਸਟਰੀ ਗਤਿਵਿਧੀ, ਅਤੇ ਸੁਰੱਖਿਆ ਸੀਮਾਵਾਂ ਲਾਗੂ ਕਰਨਾ। ਅਮਲਦਾਰ ਵਾਅਦਾ ਸਧਾਰਨ ਹੈ: ਜਦੋਂ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ OS ਕੀ ਕਰ ਰਿਹਾ ਹੈ, ਤੁਸੀਂ ਅਨੁਮਾਨ ਛੱਡ ਕੇ ਸਮਝਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ।
ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਬਹੁਤੇ ਓਪਰੇਸ਼ਨਲ ਲੱਛਣ ਪਰੋਖ ਹੁੰਦੇ ਹਨ। “ਮਸ਼ੀਨ ਸੁਸਤ ਹੈ” CPU ਟਕਰਾਅ, ਇੱਕ ਹੀ ਹੌਟ ਥ੍ਰੈਡ, ਡਰਾਈਵਰ ਇੰਟਰਪਟ ਸਟਾਰਮ, paging ਦਬਾਅ, ਜਾਂ ਐਂਟੀਵਾਇਰਸ ਫਿਲਟਰ ਹੋ ਸਕਦਾ ਹੈ। “ਇਹ ਹਨਗ ਕਰ ਜਾਂਦਾ ਹੈ” ਡੈਡਲੌਕ, ਅਟਕੀ ਨੈੱਟਵਰਕ ਕਾਲ, ਸਟੋਰੇਜ ਟਾਈਮਆਊਟ, ਜਾਂ ਕਿਸੇ ਡੀਪੈਂਡੈਂਸੀ 'ਤੇ ਮਨਜ਼ੂਰ ਸਰਵਿਸ ਹੋ ਸਕਦੀ ਹੈ। Internals ਗਿਆਨ ਅਸਪਸ਼ਟ ਸ਼ਿਕਾਇਤਾਂ ਨੂੰ ਟੈਸਟ ਕਰਨਯੋਗ ਹਾਈਪੋਥੇਸਿਸ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਯੂਜ਼ਰ ਮੋਡ ਓਥੇ ਹੈ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਐਪਸ ਅਤੇ ਸਰਵਿਸ ਚਲਦੇ ਹਨ। ਜਦੋਂ ਉਹ ਕ੍ਰੈਸ਼ ਹੁੰਦੇ ਹਨ, ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ ਉਹੀ ਬਣਦੇ ਹਨ। ਕਰਨਲ ਮੋਡ ਓਥੇ ਹੈ ਜਿੱਥੇ Windows ਆਪਣੇ ਆਪ ਅਤੇ ਡਰਾਈਵਰ ਚਲਦੇ ਹਨ; ਉੱਥੇ ਸਮੱਸਿਆਆਂ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ, bugcheck (blue screen) ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਜਾਂ ਚੁਪਕੇ ਭਰੋਸੇਯੋਗਤਾ ਘਟਾ ਸਕਦੀਆਂ ਹਨ।
ਤੁਹਾਨੂੰ ਗਹਿਰੀ ਥਿਊਰੀ ਦੀ ਲੋੜ ਨਹੀਂ—ਸਿਰਫ ਇੰਨੀ ਜਾਣਕਾਰੀ ਜਿਤਨੀ ਸਬੂਤ ਚੁਣਣ ਲਈ ਲੋੜੀਂਦੀ ਹੈ। ਇੱਕ ਐਪ ਜੋ CPU ਦਾ ਉਪਜਾ ਰਿਹਾ ਹੈ ਅਕਸਰ ਯੂਜ਼ਰ ਮੋਡ ਹੁੰਦਾ ਹੈ; ਵਾਰ-ਵਾਰ ਸਟੋਰੇਜ ਰੀਸੈਟ ਜਾਂ ਨੈੱਟਵਰਕ ਡਰਾਈਵਰ ਮੁੱਦੇ ਅਕਸਰ ਕਰਨਲ ਮੋਡ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ।
Russinovich ਦੀ ਸੋਚ—ਜੋ Sysinternals ਅਤੇ Windows Internals ਵਿੱਚ ਦਰਸਾਈ ਗਈ ਹੈ—“ਸਬੂਤ ਪਹਿਲਾਂ” ਹੈ। ਸੈਟਿੰਗਾਂ ਬਦਲਣ, ਬਿਨਾਂ ਸੋਚੇ ਰੀਬੂਟ ਕਰਨ ਜਾਂ ਰੀਇੰਸਟਾਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਕੀ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਉਹ ਕੈਪਚਰ ਕਰੋ: ਕਿਹੜਾ ਪ੍ਰੋਸੈਸ, ਕਿਹੜਾ ਥ੍ਰੈਡ, ਕਿਹੜਾ ਹੈਂਡਲ, ਕਿਹੜੀ ਰਜਿਸਟਰੀ ਕੀ, ਕਿਹੜਾ ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨ, ਕਿਹੜਾ ਡਰਾਈਵਰ, ਕਿਹੜਾ ਇਵੈਂਟ।
ਜਦੋਂ ਤੁਸੀਂ “Windows ਹੁਣ ਕੀ ਕਰ ਰਹੀ ਹੈ, ਅਤੇ ਕਿਉਂ” ਦਾ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ, ਤਾਂ ਫਿਕਸ ਛੋਟੇ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਜ਼ਿਆਦਾ ਵਾਜਬ ਬਣ ਜਾਂਦੇ ਹਨ—ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਕੰਮ ਰReactive ਫਾਇਰਫਾਈਟਿੰਗ ਰੋਂ ਬਚ ਕੇ ਪ੍ਰੀਮਬੰਧਿਤ ਬਣ ਜਾਂਦਾ ਹੈ।
Sysinternals ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਤੌਰ 'ਤੇ Windows ਲਈ ਇੱਕ “ਵਿਜ਼ੀਬਿਲਟੀ ਟੂਲਕਿਟ” ਵਜੋਂ ਸਮਝੋ: ਛੋਟੇ, ਪੋਰਟੇਬਲ ਯੂਟਿਲਿਟੀ ਜੋ ਸਿਸਟਮ ਦੇ ਅਸਲ ਵਿਹਾਰ ਨੂੰ ਪ੍ਰਕਾਸ਼ ਵਿੱਚ ਲਿਆਉਂਦੀਆਂ ਹਨ—ਪ੍ਰੋਸੈਸ-ਦਰ-ਪ੍ਰੋਸੈਸ, ਹੈਂਡਲ-ਦਰ-ਹੈਂਡਲ, ਰਜਿਸਟਰੀ ਕੀ-ਦਰ-ਕੀ। Windows ਨੂੰ ਕਾਲੇ ਡੱਬੇ ਵੱਜੋਂ ਦੇਖਣ ਦੀ ਬਜਾਏ, Sysinternals ਤੁਹਾਨੂੰ ਵੇਖਣ ਦਿੰਦਾ ਹੈ ਕਿ “ਐਪ ਸੁਸਤ ਹੈ” ਜਾਂ “CPU ਉੱਚਾ ਹੈ” ਵਰਗੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੇ ਪਿੱਛੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ।
ਓਪਰੇਸ਼ਨਲ ਦਰਦ ਅਕਸਰ ਵਾਜਬ-ਲੱਗਣ ਵਾਲੇ ਅਨੁਮਾਨਾਂ ਕਾਰਨ ਹੁੰਦਾ ਹੈ: ਇਹ ਹੋਵੇਗਾ DNS, ਮੁਮਕਿਨ ਹੈ ਐਂਟੀਵਾਇਰਸ, Windows Update ਫਿਰ ਫਸਿਆ ਹੋਇਆ ਹੋਵੇਗਾ। Sysinternals ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਸਧਾਰਨ ਹੈ: ਆਪਣੇ ਅਨੁਮਾਨਾਂ ਨੂੰ ਹਾਈਪੋਥੇਸਿਸ ਬਣਾਉਣ ਲਈ ਵਰਤੋਂ, ਫਿਰ ਸਬੂਤ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ।
ਜਦੋਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜਾ ਪ੍ਰੋਸੈਸ CPU ਖਾ ਰਿਹਾ ਹੈ, ਕਿਹੜਾ ਥ੍ਰੈਡ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ, ਕਿਹੜਾ ਫਾਈਲ ਪਾਥ ਬਰਿਟ ਰਹਿਆ ਹੈ, ਜਾਂ ਕਿਹੜੀ ਰਜਿਸਟਰੀ ਕੀ ਮੁੜ-ਲਿਖੀ ਜਾ ਰਹੀ ਹੈ, ਤੁਸੀਂ ਰਾਏਆਂ ਦੀ ਮਰਕਰਬੰਦੀ ਛੱਡ ਕੇ ਕਾਰਨਾਂ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ। ਇਹ ਬਦਲਾਅ—ਕਥਾ ਤੋਂ ਮਾਪ ਤੱਕ—internals ਗਿਆਨ ਨੂੰ ਪ੍ਰਾਇਚੁੱਕ ਤਰੀਕੇ ਨਾਲ ਵਰਤੀਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਇਹ ਟੂਲ “ਸਭ ਕੁਝ ਅੱਗ ਉੱਤੇ” ਪਲ ਦੇ ਲਈ ਬਣਾਏ ਗਏ ਹਨ:
ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਲੰਬੇ ਸੈੱਟਅਪ ਚੱਕਰ, ਭਾਰੀ ਏਜੈਂਟ ਰੋਲਆਊਟ, ਜਾਂ ਬਿਹਤਰ ਡੇਟਾ ਇਕੱਤਰ ਕਰਨ ਲਈ ਰੀਬੂਟ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੁੰਦਾ, ਇਹ ਫੈਕਟਰ ਮਹੱਤਵਪੂਰਨ ਬਣ ਜਾਂਦੇ ਹਨ।
Sysinternals ਤਾਕਤਵਰ ਹੈ, ਅਤੇ ਤਾਕਤ ਦੇ ਨਾਲ ਗਾਰਡਰੇਲ ਵੀ ਲੋੜੀਦੇ ਹਨ:
ਇਸ ਤਰ੍ਹਾਂ ਵਰਤਣ 'ਤੇ, Sysinternals ਇੱਕ ਅਨੁਸ਼ਾਸਿਤ ਤਰੀਕਾ ਬਣ ਜਾਂਦਾ ਹੈ: ਅਦ੍ਰਿਸ਼੍ਯ ਨੂੰ ਨਿਰੀਖਣ ਕਰੋ, ਸਚ ਨੂੰ ਮਾਪੋ, ਅਤੇ ਉਹ ਬਦਲਾਅ ਕਰੋ ਜੋ ਵਾਜਬ ਹੋਣ।
ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਐਡਮਿਨ ਟੂਲਕਿੱਟ ਵਿੱਚ ਸਿਰਫ਼ ਦੋ Sysinternals ਟੂਲ ਰੱਖ ਸਕਦੇ ਹੋ, ਤਾਂ ਉਹ ਹਨ Process Explorer ਅਤੇ Process Monitor। ਇਹ ਦੋਵੇਂ ਮਿਲਕੇ ਸਭ ਤੋਂ ਆਮ “Windows ਹੁਣ ਕੀ ਕਰ ਰਿਹਾ ਹੈ?” ਸਵਾਲਾਂ ਨੂੰ ਬਿਨਾ ਏਜੈਂਟ, ਰੀਬੂਟ ਜਾਂ ਭਾਰੀ ਸੈਟਅਪ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ।
Process Explorer Task Manager ਨਾਲੋਂ x-ray ਵਿਜ਼ਨ ਵਰਗਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਮਸ਼ੀਨ ਧੀਮੀ ਜਾਂ ਅਸਥਿਰ ਹੋਈ ਹੈ, ਇਹ ਤੁਹਾਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪ੍ਰੋਸੈਸ ਜਿੰਮੇਵਾਰ ਹੈ ਅਤੇ ਇਹ ਕਿਹੜਿਆਂ ਚੀਜ਼ਾਂ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ।
ਇਹ ਖ਼ਾਸ ਕਰਕੇ ਲਾਭਦਾਇਕ ਹੈ:
ਆਖਰੀ ਨੁਕਤਾ ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਇੱਕ ਸੁਪਰਪਾਵਰ ਹੈ: “ਮੈਂ ਇਹ ਫ਼ਾਇਲ ਡਿਲੀਟ ਕਿਉਂ ਨਹੀਂ ਕਰ ਸਕਦਾ?” ਆਮ ਤੌਰ 'ਤੇ ਬਣ ਜਾਂਦਾ ਹੈ “ਇਹ ਸਰਵਿਸ ਇਸ ਨੂੰ ਖੁੱਲਾ ਹੈਂਡਲ ਰੱਖੇ ਹੋਈ ਹੈ।”
Process Monitor (Procmon) ਫ਼ਾਇਲ ਸਿਸਟਮ, ਰਜਿਸਟਰੀ, ਅਤੇ ਪ੍ਰੋਸੈਸ/ਥ੍ਰੈਡ ਕਾਰਵਾਈਆਂ 'ਤੇ ਵੇਰਵੇਦਾਰ ਇਵੈਂਟ ਕੈਪਚਰ ਕਰਦਾ ਹੈ। ਇਹ ਉਹ ਟੂਲ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਪੁੱਛਦੇ ਹੋ: “ਐਪ ਹੰਗ ਹੋਣ ਵੇਲੇ ਕੀ ਬਦਲਿਆ?” ਜਾਂ “ਕੌਣ ਡਿਸਕ 'ਤੇ ਹਰ 10 ਮਿੰਟ ਵਿੱਚ ਹਮਲਾ ਕਰ ਰਿਹਾ ਹੈ?”
Capture ਤੋਂ ਪਹਿਲਾਂ, ਸਵਾਲ ਫ੍ਰੇਮ ਕਰੋ:
Procmon ਤੁਸੀਂ ਨੂੰ ਓਵਰਹੈਲਮ ਕਰ ਸਕਦਾ ਹੈ ਜੇ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਕੁਝ ਕੈਪਚਰ ਕਰੋ। ਤੇਜ਼ ਸ਼ੁਰੂਅਾਤ ਲਈ:
ਆਮ ਨਤੀਜੇ ਬਹੁਤ ਵਿਆਵਹਾਰਿਕ ਹੁੰਦੇ ਹਨ: ਇਕ ਗੜਬੜੀ ਵਾਲੀ ਸਰਵਿਸ ਜੋ ਇਕ ਗੁੰਮ ਰਜਿਸਟਰੀ ਕੀ ਨੂੰ ਵਾਰ-ਵਾਰ ਪੁੱਛਦੀ ਹੈ, ਇੱਕ ਰਨਅਵੇ “ਰੀਅਲ-ਟਾਈਮ” ਫ਼ਾਇਲ ਸਕੈਨ ਜੋ ਹਜ਼ਾਰਾਂ ਫ਼ਾਇਲਾਂ ਨੂੰ ਛੇੜਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਗੁੰਮ ਹੋਈ DLL ਲੋਡ ਕੋਸ਼ਿਸ਼ (“NAME NOT FOUND”) ਜੋ ਇਹ ਸਮਝਾਉਂਦਾ ਹੈ ਕਿ ਕਿਉਂ ਕੋਈ ਐਪ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਨਹੀਂ ਚਲਦਾ ਪਰ ਦੂਜੇ 'ਤੇ ਚੱਲਦਾ ਹੈ।
ਜਦੋਂ ਇੱਕ Windows ਮਸ਼ੀਨ “ਅਜਿਹਾ ਮਹਿਸੂਸ” ਕਰਦੀ ਹੈ, ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰੇ ਮਾਨੀਟਰਿੰਗ ਸਟੈਕ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਕੁਝ ਛੋਟੇ Sysinternals ਟੂਲ ਤੇਜ਼ੀ ਨਾਲ ਤਿੰਨ ਪ੍ਰਯੋਗਿਕ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ: ਕੀ ਆਪਣੇ ਆਪ ਚੱਲਦਾ ਹੈ? ਕੌਣ ਨੈੱਟਵਰਕ 'ਤੇ ਗੱਲ ਕਰ ਰਿਹਾ ਹੈ? ਮੈਮੋਰੀ ਕਿੱਥੇ ਗਈ?
Autoruns ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਸਮਝਣ ਦਾ ਕਿ ਹਰ ਉਹ ਚੀਜ਼ ਕਿੰਨੀ ਆਪਣੇ ਆਪ ਚੱਲ ਸਕਦੀ ਹੈ: ਸੇਵਾਵਾਂ, ਨਿਯਤ ਟਾਸਕ, ਸ਼ੈੱਲ ਐਕਸਟੈਂਸ਼ਨ, ਡਰਾਈਵਰ, ਅਤੇ ਹੋਰ।
ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਸਟਾਰਟਅਪ ਆਈਟਮ ਆਮ ਤੌਰ 'ਤੇ ਸੁਸਤ ਬੂਟ, ਇੰਟਰਮੀਟੈਂਟ ਹੈਂਗ, ਅਤੇ ਲੌਗਿਨ-ਬਾਅਦ CPU ਸਪਾਇਕ ਦੇ ਸਰੋਤ ਹੁੰਦੇ ਹਨ। ਇਕ ਅਸਥਿਰ ਅਪਡੇਟਰ, ਲੇਗੇਸੀ ਡਰਾਈਵਰ ਮਦਦਗਾਰ, ਜਾਂ ਟੁੱਟੀ ਸ਼ੈੱਲ ਐਕਸਟੈਂਸ਼ਨ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੀ ਹੈ।
ਵਿਹਾਰਕ ਸੁਝਾਅ: ਉਹ ਐਂਟਰੀਜ਼ ਦੇਖੋ ਜੋ unsigned, ਹਾਲ ਹੀ ਵਿੱਚ ਜੋੜੀ ਗਈ ਜਾਂ ਲੋਡ ਹੋਣ ਵਿੱਚ ਅਸਫਲ ਹਨ। ਜੇ ਕਿਸੇ ਆਈਟਮ ਨੂੰ ਅਣ-ਸਕ੍ਰੋਲ ਕਰਨ ਨਾਲ ਬਾਕੀ ਸਿਸਟਮ ਸਥਿਰ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਅਸਪਸ਼ਟ ਲੱਛਣ ਨੂੰ ਇੱਕ ਨਿਰਧਾਰਤ ਕੰਪੋਨੈਂਟ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਹੈ।
TCPView ਤੁਹਾਨੂੰ ਪ੍ਰੋਸੈਸ ਨਾਂ ਅਤੇ PID ਨਾਲ ਜੁੜੇ ਐਕਟੀਵ ਕਨੈਕਸ਼ਨ ਅਤੇ ਲਿਸਨਰ ਦਾ ਤੁਰੰਤ ਮੈਪ ਦਿੰਦਾ ਹੈ। ਇਹ ਛੇਤੀ ਚੈਕ ਲਈ ਉਤਮ ਹੈ:
ਇਹ ਸੁਰੱਖਿਆ ਦੀ ਜਾਂਚ ਲਈ ਹੀ ਨਹੀਂ; ਇਹ ਰਨਅਵੇ ਏਜੈਂਟ, ਗਲਤ ਕੰਫਿਗਰਡ ਪ੍ਰਾਕਸੀ, ਜਾਂ “ਰੀਟ੍ਰਾਈ ਸਟਾਰਮ” ਖੋਲ ਸਕਦਾ ਹੈ ਜਿਥੇ ਐਪ ਧੀਮਾ ਲੱਗਦਾ ਹੈ ਪਰ ਅਸਲ ਮੁੱਦਾ ਨੈੱਟਵਰਕ ਵਿਹਾਰ ਹੈ।
RAMMap ਤੁਹਾਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ RAM ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਹਾਜ਼ਰ ਹੈ।
ਉਪਯੋਗੀ ਬੇਸਲਾਈਨ ਫਰਕ:
ਜੇ ਯੂਜ਼ਰ “ਘੱਟ ਮੈਮੋਰੀ” ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ ਜਦ Task Manager ਮਨ-ਮੁਟਾਬਕ ਨਹੀਂ ਦਿਖਾਉਂਦਾ, ਤਾਂ RAMMap ਸਾਬਤ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਗਰੋਥ ਹੈ, ਭਾਰਾ ਫ਼ਾਇਲ ਕੈਸ਼ ਹੈ, ਜਾਂ ਕੋਈ ਡਰਾਈਵਰ nonpaged memory ਖਾ ਰਿਹਾ ਹੈ।
ਜੇ ਕੋਈ ਐਪ ਦਿਨਾਂ ਵਿੱਚ ਧੀਰੇ-ਧੀਰੇ ਸੁਸਤ ਹੋ ਰਿਹਾ ਹੈ, Handle ਹੈਂਡਲ ਗਿਣਤੀ ਦੀ ਨਿਰੰਤਰ ਵਾਧੇ ਦੀ ਪਛਾਣ ਕਰ ਸਕਦਾ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ ਲੀਕ ਪੈਟਰਨ)। VMMap ਉਹਦੋਂ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦ ਮੈਮੋਰੀ ਵਰਤੋਂ ਅਜੀਬ ਹੋਵੇ—ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ, ਵੱਡੇ ਰਿਜ਼ਰਵਡ ਖੇਤਰ, ਜਾਂ ਐਲੋਕੇਸ਼ਨ ਜੋ ਸਧਾਰਨ “private bytes” ਵਜੋਂ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੇ।
Windows ਓਪਰੇਸ਼ਨ ਅਕਸਰ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਮਿਲ ਜਾਂਦੀਆਂ ਹਨ: Event Viewer ਅਤੇ Task Manager ਦੇ ਕੁਝ ਸਕ੍ਰੀਨਸ਼ਾਟ। ਇਹ breadcrumbs ਲਈ ਠੀਕ ਹੈ, ਪਰ ਭਰੋਸੇਯੋਗ ਇੰਸਿਡੈਂਟ ਰਿਸਪਾਂਸ ਲਈ ਤਿੰਨ ਪੂਰਕ ਸਿਗਨਲਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਲੌਗ (ਕੀ ਹੋਇਆ), ਮੈਟ੍ਰਿਕਸ (ਕਿੰਨਾ ਖਰਾਬ ਹੋਇਆ), ਅਤੇ ਟਰੇਸ (ਸਿਸਟਮ ਹਰ ਪਲ ਕੀ ਕਰ ਰਿਹਾ ਸੀ)।
Windows Event logs ਪਛਾਣ, ਸਰਵਿਸ ਲਾਈਫਸਾਈਕਲ, ਨੀਤੀ ਬਦਲਾਵ ਅਤੇ ਐਪ-ਲੇਵਲ ਐਰਰ ਲਈ ਬਹੁਤ ਉਪਯੋਗ ਹਨ। ਫਿਰ ਵੀ ਉਹ ਅਸਮਾਨ ਹਨ: ਕੁਝ ਕੰਪੋਨੈਂਟ ਵਧੀਆ ਲੌਗ ਕਰਦੇ ਹਨ, ਹੋਰ ਕਮੀਨਕ ਦੀ ਲਿਖਤੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸੁਨੇਹੇ ਅਕਸਰ vague ਹੁੰਦੇ ਹਨ (“The application stopped responding”)। ਉਨ੍ਹਾਂ ਨੂੰ ਟਾਈਮਲਾਈਨ ਐਂਕਰ ਵਜੋਂ ਵਰਤੋਂ, ਸਾਰਾ ਕਹਾਣੀ ਨਹੀਂ ਮੰਨੋ।
ਆਮ ਫਾਇਦੇ:
Performance counters (ਅਤੇ ਮਿਲਦੇ-ਜੁਲਦੇ ਸਰੋਤ) ਉੱਤਰ ਦਿੰਦੀਆਂ ਹਨ, “ਕੀ ਮਸ਼ੀਨ ਸਿਹਤਮੰਦ ਹੈ?” ਆਉਟੇਜ ਦੌਰਾਨ ਸ਼ੁਰੂਆਤ ਲਈ:
ਮੈਟ੍ਰਿਕਸ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦੱਸਦੀਆਂ ਕਿ ਕਿਉਂ spike ਆਇਆ, ਪਰ ਉਹ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਕਦੋਂ ਇਹ ਸ਼ੁਰੂ ਹੋਇਆ ਅਤੇ ਕੀ ਇਹ ਸੁਧਰ ਰਿਹਾ ਹੈ।
Event Tracing for Windows (ETW) Windows ਦਾ ਬਿਲਟ-ਇਨ ਫਲਾਈਟ ਰਿਕਾਰਡਰ ਹੈ। ad-hoc ਟੈਕਸਟ ਸੁਨੇਹਿਆਂ ਦੀ ਥਾਂ, ETW ਕਰਨਲ, ਡਰਾਈਵਰਾਂ ਅਤੇ ਸਰਵਿਸਾਂ ਤੋਂ ਸਟਰੱਕਚਰਡ ਘਟਨਾਵਾਂ high volume 'ਤੇ ਨਿਕਲਵਾਂਦਾ ਹੈ—ਪ੍ਰੋਸੈਸ/ਥ੍ਰੈਡ ਐਕਟਿਵਿਟੀ, ਫ਼ਾਇਲ I/O, ਰਜਿਸਟਰੀ ਐਕਸੇਸ, TCP/IP, ਸ਼ੈਡਿਊਲਿੰਗ ਅਤੇ ਹੋਰ। ਬਹੁਤ ਸਾਰੇ “ਰਹਸਮਈ ਅਟਕਣ” ਇਥੇ ਸਮਝਾਏ ਜਾ ਸਕਦੇ ਹਨ।
ਇੱਕ ਆਮ ਨਿਯਮ:
“ਹਮੇਸ਼ਾ ਸਭ ਕੁਝ ਚਾਲੂ ਰੱਖੋ” ਤੋਂ ਬਚੋ। ਇੱਕ ਛੋਟੀ ਹਮੇਸ਼ਾ-ਚਾਲੂ ਬੇਸਲਾਈਨ (ਮੁੱਖ ਲੌਗ + ਕੋਰ ਮੈਟ੍ਰਿਕਸ) ਰੱਖੋ ਅਤੇ ਇੰਸਿਡੈਂਟ ਦੌਰਾਨ ਨਿਸ਼ਾਨੇਵੰਦ ETW ਕੈਪਚਰ ਵਰਤੋ।
ਸਭ ਤੋਂ ਤੇਜ਼ ਨਿਰਣਯ Leਅ ਤਿੰਨ ਘੜੀਆਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਆਉਂਦੇ ਹਨ: ਯੂਜ਼ਰ ਰਿਪੋਰਟ (“10:42 'ਤੇ ਇਹ ਹਨਗ ਹੋਇਆ”), ਮੈਟ੍ਰਿਕ ਅੰਕੜਿਆਂ 'ਤੇ ਇਨਫਲੈਕਸ਼ਨ (CPU/disk spike), ਅਤੇ ਲੌਗ/ETW ਘਟਨਾਵਾਂ ਇੱਕੋ ਟਾਈਮਸਟੈਂਪ 'ਤੇ। ਜਦੋਂ ਤੁਹਾਡੇ ਡੇਟਾ ਦਾ ਸਮਾਂ ਇੱਕੋ ਹੋਵੇ, ਤਾਂ ਆਉਟੇਜ ਅਨੁਮਾਨ ਤੋਂ ਕਹਾਣੀਆਂ ਬਣ ਕੇ ਪ੍ਰਮਾਣਿਤ ਹੋ ਜਾਂਦੇ ਹਨ।
Windows ਦੇ ਡਿਫੋਲਟ ਇਵੈਂਟ ਲੌਗ ਉਪਯੋਗ ਹਨ, ਪਰ ਕਈ ਵਾਰ ਉਹ “ਹੁਣ ਕਿਉਂ?” ਦੇ ਉਹ ਵੇਰਵੇ ਛੱਡ ਦਿੰਦੇ ਹਨ ਜੋ ਆਪਰੇਟਰਾਂ ਨੂੰ ਚਾਹੀਦੇ ਹਨ। Sysmon (System Monitor) ਉਹ ਖਾਲੀ ਗੈਰ-ਪੂਰਨ ਡੇਟਾ ਭਰ ਦਿੰਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਲਾਂਚ, ਪਰਸਿਸਟੈਂਸੀ, ਅਤੇ ਡਰਾਈਵਰ ਵਿਹਾਰ ਦੇ ਆਸਪਾਸ।
Sysmon ਦੀ ਤਾਕਤ ਸੰਦਰਭ ਹੈ। “ਇੱਕ ਸੇਵਾ ਸਟਾਰਟ ਹੋਈ” ਦੀ ਥਾਂ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿਸ ਪ੍ਰੋਸੈਸ ਨੇ ਉਸਨੂੰ ਸ਼ੁਰੂ ਕੀਤਾ, ਪੂਰਾ ਕਮਾਂਡ ਲਾਈਨ, ਪੈਰੇਂਟ ਪ੍ਰੋਸੈਸ, ਹੈਸ਼, ਯੂਜ਼ਰ ਖਾਤਾ, ਅਤੇ correlation ਲਈ ਸਾਫ਼ ਟਾਈਮਸਟੈਂਪ।
ਇਹ ਭਰੋਸੇਯੋਗਤਾ ਕੰਮ ਲਈ ਕੀਮਤੀ ਹੈ ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਇੰਸਿਡੈਂਟ “ਛੋਟੇ” ਬਦਲਾਅ ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਨਵਾਂ ਨਿਯਤ ਟਾਸਕ, ਇੱਕ ਚੁਪ ਅੱਪਡੇਟਰ, ਇੱਕ ਗੁੰਮ ਹੋਇਆ ਸਕ੍ਰਿਪਟ, ਜਾਂ ਕੋਈ ਡਰਾਈਵਰ ਜੋ ਬੁਰਾ ਵਰਤਾਰਾ ਕਰਦਾ ਹੈ।
“ਸਭ ਕੁਝ ਲੌਗ ਕਰੋ” ਵਾਲਾ Sysmon ਕਾਨਫਿਗ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲੀ ਚੋਣ ਨਹੀਂ। ਇੱਕ ਨਿਯਨਤਮ, ਭਰੋਸੇਯੋਗਤਾ-ਕੇਂਦਰਿਤ ਸੈਟਿੰਗ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਵਿਸਥਾਰ ਕਰੋ।
ਸ਼ੁਰੂਆਤ ਲਈ ਚੰਗੇ ਉਮੀਦੀ ਚੀਜ਼ਾਂ:
Include rule ਨਾਲ ਸੰਦ ਢੋਣਗੇ (ਮਹੱਤਵਪੂਰਨ ਸਰਵਰ, ਮਾਲੂਮ ਸੇਵਾ اکਾਊਂਟ) ਅਤੇ exclude rule ਨਾਲ ਸ਼ੋਰ ਘਟਾਓ (ਔਪਡੀਟਰਲਾਂ, ਭਰੋਸੇਯੋਗ ਮੈਨੇਜਮੈਂਟ ਏਜੰਟ) ਤਾਂ ਕਿ ਸਿਗਨਲ ਪੜ੍ਹਨਯੋਗ ਰਹੇ।
Sysmon ਅਕਸਰ ਆਮ “ਰਹਸਮਈ ਬਦਲਾਵ” ਸਥਿਤੀਆਂ ਦੀ ਪੁਸ਼ਟੀ ਜਾਂ ਖੰਡਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ:
ਪਹਿਲਾਂ ਪ੍ਰਤੀਨਿਧੀ ਮਸ਼ੀਨਾਂ 'ਤੇ ਪ੍ਰਭਾਵ ਦੀ ਜਾਂਚ ਕਰੋ। Sysmon ਡਿਸਕ I/O ਅਤੇ ਇਵੈਂਟ ਵਾਲੀਊਮ ਵਧਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੇਂਦਰਕ ਸੰਗ੍ਰਹਿ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ।
ਕਮਾਂਡ ਲਾਈਨਾਂ, ਯੂਜ਼ਰਨੇਮਸ, ਅਤੇ ਪਾਥਾਂ ਵਰਗੇ ਫੀਲਡ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋ ਸਕਦੇ ਹਨ—ਆਮ ਰੋਲਆਊਟ ਤੋਂ ਪਹਿਲਾਂ ਐਕਸੈੱਸ ਕੰਟਰੋਲ, ਰੀਟੇਨਸ਼ਨ ਸੀਮਾਵਾਂ, ਅਤੇ ਫਿਲਟਰਿੰਗ ਲਗਾਓ।
Sysmon ਸਭ ਤੋਂ ਕੀਮਤੀ breadcrumbs ਵਜੋਂ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ। ETW ਲਈ ਡੀਪ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਸ਼ਨਾਂ, ਮੈਟ੍ਰਿਕਸ ਲਈ ਰੁਝਾਨ ਪਤਾ ਕਰਨ, ਅਤੇ ਅਨੁਸ਼ਾਸਿਤ ਇੰਸਿਡੈਂਟ ਨੋਟਸ ਨਾਲ ਮਿਲਾ ਕੇ ਵਰਤੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਦਲਾਅ ਨੇ ਕੀ ਤੋੜਿਆ ਤੇ ਤੁਸੀਂ ਕਿਵੇਂ ਠੀਕ ਕੀਤਾ—ਇਹ ਜੋੜ ਸਕੋ।
ਜਦੋਂ ਕੁਝ “ਸਿਰਫ਼ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ” ਹੈ, ਸਭ ਤੋਂ ਕੀਮਤੀ ਆਰਟੀਫੈਕਟ ਅਕਸਰ ਡੰਪ ਫ਼ਾਇਲ ਹੁੰਦੀ ਹੈ: ਮੈਮੋਰੀ ਦਾ ਸ્નੈਪਸ਼ਾਟ ਅਤੇ ਕਾਫ਼ੀ ਐਕਜ਼ੈਕਿਊਸ਼ਨ ਸਟੇਟ ਤਾਂ ਜੋ ਤੁਸੀਂ ਫੇਲ੍ਹਅਰ ਹੋਣ ਵੇਲੇ ਪ੍ਰੋਸੈਸ (ਜਾਂ OS) ਕੀ ਕਰ ਰਹੀ ਸੀ ਇਹ ਮੁੜ ਬਣਾਉ ਸਕੋ। ਲੌਗਾਂ ਦੇ ਵਿਰੁੱਧ, ਡੰਪਾਂ ਲਈ ਤੁਸੀਂ ਸਹੀ ਸੁਨੇਹਾ ਪਹਿਲਾਂ ਅਨੁਮਾਨ ਨਹੀਂ ਕਰਨਾ ਪੈਂਦਾ—ਉਹ ਘਟਨਾ ਦੇ ਬਾਅਦ ਸਬੂਤ ਕੈਪਚਰ ਕਰ ਲੈਂਦੇ ਹਨ।
ਡੰਪ ਇੱਕ ਨਿਰਧਾਰਤ ਮੌਡੀਊਲ, ਕਾਲ ਪਾਥ, ਅਤੇ ਫੇਲ੍ਹਅਰ ਕਿਸਮ (access violation, heap corruption, deadlock, driver fault) ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦੇ ਹਨ—ਜੋ ਕੇ ਲੱਛਣਾਂ ਤੋਂ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਮੁਸ਼ਕਿਲ ਹੈ।
WinDbg ਇੱਕ ਡੰਪ ਨੂੰ ਕਹਾਣੀ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਜਰੂਰੀ ਗੱਲਾਂ:
ਆਮ ਵਰਕਫਲੋ: ਡੰਪ ਖੋਲ੍ਹੋ → symbols ਲੋਡ ਕਰੋ → automated analysis ਚਲਾਓ → ਸਿਖਰ ਦੇ stacks ਅਤੇ ਸ਼ਾਮਿਲ ਮੌਡੀਊਲਾਂ ਨਾਲ ਵੈਰਿਫਾਈ ਕਰੋ।
“ਇਹ ਫ੍ਰੀਜ਼ ਹੋ ਗਿਆ” ਇੱਕ ਲੱਛਣ ਹੈ, ਨਾਂ ਕਿ ਨਿਰੀਖਣ। ਹੈਂਗ ਲਈ, ਐਪ ਅਣਪ੍ਰਤਿਕਾਰ ਹੋਣ ਦੀ ਸਥਿਤੀ 'ਤੇ ਡੰਪ ਕੈਪਚਰ ਕਰੋ ਅਤੇ ਜਾਂਚ ਕਰੋ:
ਤੁਸੀਂ ਅਕਸਰ ਸਪਸ਼ਟ ਮੁੱਦਿਆਂ ਦਾ ਖੁਦ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕਦੇ ਹੋ (ਇੱਕ ਮੌਡੀਊਲ ਵਿੱਚ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਕ੍ਰੈਸ਼, ਸਪਸ਼ਟ ਡੈਡਲੌਕ, ਕਿਸੇ ਖਾਸ DLL/ਡਰਾਈਵਰ ਨਾਲ ਮਜ਼ਬੂਤ ਸੰਬੰਧ)। ਜਦ ਡੰਪ ਤੀਸਰੇ-ਪੱਖੀ ਡਰਾਈਵਰ/ਸੁਰੱਖਿਆ ਸੌਫਟਵੇਅਰ ਜਾਂ ਕਰਨਲ ਕੰਪੋਨੈਂਟ implicate ਕਰਣ, ਜਾਂ symbols/source ਦੀ ਘਾਟ ਹੋਵੇ—ਤਾਂ vendor ਜਾਂ Microsoft ਨੂੰ escalate ਕਰੋ ਤਾਂ ਕਿ ਪੂਰੀ ਚੇਨ ਦੀ ਵਿਆਖਿਆ ਕੀਤੀ ਜਾ ਸਕੇ।
ਕਈ “ਰਹਸਮਈ Windows ਮੁੱਦੇ” ਇਕੋ ਜਿਹੇ ਪੈਟਰਨ ਦੁਹਰਾਉਂਦੇ ਹਨ। ਅੰਤਰ Guess ਅਤੇ Fix ਦੇ ਵਿਚਕਾਰ ਇਹ ਜਾਣਨਾ ਹੈ ਕਿ OS ਕੀ ਕਰ ਰਿਹਾ ਹੈ—ਅਤੇ Internals/Sysinternals ਦਿਮਾਗ਼ੀ ਨਕਸ਼ਾ ਤੁਹਾਨੂੰ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ।
ਜਦ ਲੋਕ ਕਹਿੰਦੇ ਹਨ “ਐਪ ਮੈਮੋਰੀ ਲੀਕ ਕਰ ਰਿਹਾ ਹੈ”, ਉਹ ਅਕਸਰ ਦੋ ਚੀਜ਼ਾਂ ਵਿਚੋਂ ਇੱਕ ਦਾ ਮਤਲਬ ਲੈਂਦੇ ਹਨ।
Working set ਉਹ ਫ਼ਿਜ਼ਿਕਲ RAM ਹੈ ਜੋ ਵਰਕਿੰਗ ਪ੍ਰੋਸੈਸ ਸਪਰਟੀ ਨਾਲ ਹੈ। ਇਹ ਵਧ ਜਾਂ ਘਟ ਸਕਦਾ ਹੈ ਜਿਵੇਂ Windows ਮੈਮੋਰੀ ਨੂੰ trim ਕਰਦਾ ਹੈ।
Commit ਸਿਸਟਮ ਨੇ ਜੋ ਵਰਚੁਅਲ ਮੈਮੋਰੀ ਵਚਨਬੱਧ ਕੀਤੀ ਹੈ ਉਸਦੀ ਰਕਮ ਹੈ—RAM ਜਾਂ page file ਤੋਂ ਜੋ ਬੈਕ ਕਰਨੀ ਹੈ। ਜੇ commit ਲਗਾਤਾਰ ਵੱਧਦਾ ਹੈ, ਤਾਂ ਇਹ ਇਕ ਅਸਲ ਲੀਕ ਦੇਖਾਏਗਾ: ਆਖ਼ਿਰਕਾਰ ਤੁਸੀਂ commit limit ਤੇ ਪਹੁੰਚ ਜਾਓਗੇ ਅਤੇ allocations fail ਹੋਣ ਜਾਂ host ਅਸਥਿਰ ਹੋ ਸਕਦਾ ਹੈ।
ਇੱਕ ਆਮ ਲੱਛਣ: Task Manager “available RAM” ਦਿਖਾਂਦਾ ਹੈ, ਪਰ ਮਸ਼ੀਨ ਫਿਰ ਵੀ ਸੁਸਤ ਹੁੰਦੀ ਹੈ—ਕਿਉਂਕਿ ਸੰਕਟ commit, ਨਾ ਕਿ free RAM, ਹੋ ਸਕਦਾ ਹੈ।
ਹੈਂਡਲ ਇੱਕ OS ਬਜੈਕਟ ਦਾ ਸੰਦਰਭ ਹੈ (ਫ਼ਾਇਲ, ਰਜਿਸਟਰੀ ਕੀ, ਇਵੈਂਟ, ਸੈਕਸ਼ਨ ਆਦਿ)। ਜੇ ਇੱਕ ਸਰਵਿਸ ਹੈਂਡਲ ਲੀਕ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਹ ਕਈ ਘੰਟਿਆਂ ਜਾਂ ਦਿਨਾਂ ਦੌਰਾਨ ਠੀਕ ਚੱਲ ਸਕਦੀ ਹੈ, ਫਿਰ ਅਚਾਨਕ ਅਜੀਬ-errors (ਫਾਇਲ ਖੋਲ੍ਹ ਨਹੀਂ ਸਕਦੀ, threads ਨਹੀਂ ਬਣ ਸਕਦੀਆਂ, connections ਨਹੀਂ ਲੈ ਸਕਦਾ) ਦਿਖਾਈ ਦੇ ਸਕਦੀਆਂ ਹਨ ਜਦ ਪ੍ਰੋਸੈਸ-ਸਤਰ ਹੈਂਡਲ ਗਿਣਤੀ ਵਧ ਜਾਂਦੀ ਹੈ।
Process Explorer ਵਿੱਚ ਹੈਂਡਲ ਗਿਣਤੀ ਰੁਝਾਨਾਂ ਨੂੰ ਵੇਖੋ। ਇੱਕ ਲਗਾਤਾਰ ਉਭਰਦਾ ਰੁਖ ਸਖਤ ਨਿਸ਼ਾਨ ਹੈ ਕਿ ਸਰਵਿਸ ਕੁਝ ਬੰਦ ਕਰਨਾ ਭੁੱਲ ਰਹੀ ਹੈ।
ਸਟੋਰੇਜ ਮੁੱਦੇ ਪ੍ਰਾਪਤੀ ਵਿੱਚ ਹੋਰ ਪ੍ਰਗਟ ਨਹੀਂ ਹੁੰਦੇ; ਉਹ ਅਕਸਰ ਉੱਚ ਲੇਟਿਨਸੀ ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼ ਵਜੋਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। Process Monitor ਵਿੱਚ ਧਿਆਨ ਦਿਓ:
ਫਿਲਟਰ ਡਰਾਈਵਰ (AV, backup, DLP) ਵੀ I/O ਪਾਥ ਵਿੱਚ ਰੁਕਾਵਟ ਪਾ ਸਕਦੇ ਹਨ ਅਤੇ ਦੇਰੀ ਜਾਂ ਨਾਕਾਮੀਆਂ ਜੋੜ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਐਪ “ਗਲਤ” ਕੀਤੇ।
ਇੱਕ ਹੌਟ ਪ੍ਰੋਸੈਸ ਸਾਫ਼ ਸਪਸਟ ਹੈ: ਇੱਕ ਐਗਜ਼ੈਕਯੂਟੇਬਲ CPU ਖਾਂਦਾ ਹੈ।
ਸਿਸਟਮ-ਵਿਆਪੀ ਟਕਰਾਅ ਹੋਰ ਪੇਚੀਦਾ ਹੈ: CPU ਉੱਚ ਹੈ ਕਿਉਂਕਿ ਕਈ ਥ੍ਰੈਡ runnable ਹਨ ਅਤੇ locks, disk, ਜਾਂ memory ਲਈ ਲੜ ਰਹੇ ਹਨ। Internals ਸੋਚ ਤੁਹਾਨੂੰ ਪੁੱਛਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦੀ ਹੈ: “ਕੀ CPU ਵੱਖਰਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਕਿਤੇ ਹੋਰ ਅਟਕਿਆ ਹੋਇਆ ਹੈ ਜਿਸ ਲਈ spinning ਹੋ ਰਿਹਾ ਹੈ?”
ਜਦ ਟਾਈਮਆਊਟ ਹੁੰਦੇ ਹਨ, ਤਾਂ Process → connection ਨੂੰ TCPView ਜਾਂ Process Explorer ਨਾਲ ਨਕਸ਼ਾ ਬਣਾਓ। ਜੇ ਗਲਤ ਪ੍ਰੋਸੈਸ socket ਦਾ ਮਾਲਕ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਠੋਸ ਦੋਸ਼ੀ ਪਾਸਾ ਲੱਭ ਲਿਆ। ਜੇ ਠੀਕ ਪ੍ਰੋਸੀਸ socket ਦਾ ਮਾਲਕ ਹੈ, ਤਾਂ ਪੈਟਰਨ ਵੇਖੋ: SYN ਰੀਟ੍ਰਾਈਜ਼, ਲੰਬੇ-ਥਾਂ ਬੈਠੇ ਹੋਏ ਕਨੈਕਸ਼ਨ, ਜਾਂ ਛੋਟੀ-ਉਮਰ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਆਉਟਬਾਉਂਡ ਕੋਸ਼ਿਸ਼ਾਂ ਜੋ DNS/firewall/proxy ਸਮੱਸਿਆ ਵੱਲ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਨਾ ਕਿ “ਐਪ ਡਾਉਨ”।
ਭਰੋਸੇਯੋਗਤਾ ਕੰਮ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਦ ਹਰ ਇੰਸਿਡੈਂਟ ਇਕੋ ਰਸਤੇ ਤੇ ਚੱਲਦਾ ਹੈ। ਮਕਸਦ ਇਹ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਵੱਧ ਟੂਲ ਚਲਾਓ—ਬਲਕਿ ਸਥਿਰ ਸਬੂਤ ਨਾਲ ਬਿਹਤਰ ਫੈਸਲੇ ਲੈਓ।
“ਖ਼ਰਾਬ” ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ: “ਵੱਡੀ ਫ਼ਾਇਲ ਸੰਭਾਲਣ ਵੇਲੇ ਐਪ 30–60 ਸਕਿੰਟ ਲਈ ਫ੍ਰੀਜ਼ ਹੁੰਦਾ ਹੈ” ਜਾਂ “ਹਰ 10 ਮਿੰਟ ਬਾਅਦ CPU 100% ਹੋ ਜਾਂਦਾ ਹੈ”। ਜੇ ਤੁਸੀਂ ਦੁਹਰਾਉ ਸਕਦੇ ਹੋ, ਤਾਂ ਡੀਮਾੰਡ 'ਤੇ ਕਰੋ; ਜੇ ਨਹੀਂ, ਤਾਂ ਟਿਗਰ (ਸਮਾਂ, ਵਰਕਲੋਡ, ਯੂਜ਼ਰ ਐਕਸ਼ਨ) ਬਿਆਨ ਕਰੋ।
ਭਾਰੀ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲੱਛਣ ਅਤੇ ਘੇਰਾ ਪੁਸ਼ਟੀ ਕਰੋ:
ਇਹ ਥਾਂ ਤੇਜ਼ ਚੈੱਕ (Task Manager, Process Explorer, ਬੁਨਿਆਦੀ ਕਾਂਟਰੇ) ਤੁਹਾਨੂੰ ਅਗਲਾ ਕਦਮ ਚੁਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਆਪਣੇ ਸੰਗ੍ਰਹਿ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਓ ਜਿਵੇਂ ਤੁਸੀਂ ਉਹ ਕਿਸੇ ਸਹੀਕਰਮੀ ਨੂੰ ਦੇ ਰਹੇ ਹੋ ਜੋ ਮੌਕੇ 'ਤੇ ਨਹੀਂ ਸੀ। ਇੱਕ ਚੰਗੀ ਕੇਸ ਫਾਇਲ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
ਕੈਪਚਰ ਸੰਕੁਚਿਤ ਅਤੇ ਨਿਸ਼ਾਨੇਵੰਦ ਰੱਖੋ। ਇੱਕ 60 ਸਕਿੰਟ ਟਰੇਸ ਜੋ ਫੇਲ੍ਹਅਰ ਖਿੜਕੀ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, 6 ਘੰਟੇ ਦੀ ਕੈਪਚਰ ਤੋਂ ਵਧੀਕ ਲਾਭਦਾਇਕ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਖੋਲ੍ਹ ਨਹੀਂ ਸਕਦਾ।
ਤੁਹਾਡੇ ਕੋਲ ਜੋ ਇਕੱਤਰ ਕੀਤਾ ਹੈ ਉਸਨੂੰ ਸਧਾਰਨ ਕਹਾਣੀ ਵਿੱਚ ਬਦਲੋ:
ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸਾਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ ਤਾਂ ਔਰ ਸਾਫ਼-ਸੁਥਰੀ ਕੈਪਚਰ ਜਾਂ ਇੱਕ ਤੰਗ ਹਾਈਪੋਥੈਸਿਸ ਲੋੜੀਂਦੀ ਹੈ।
ਛੋਟਾ ਤੇ ਸੁਰੱਖਿਅਤ ਫਿਕਸ ਲਗਾਓ, ਫਿਰ ਉਹੀ ਦੁਹਰਾਉਂ ਆਪਣੇ ਰੀਪ੍ਰੋਡ ਕਦਮਾਂ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰੋ ਅਤੇ “ਪਹਿਲਾਂ বনਾਮ ਬਾਅਦ” ਕੈਪਚਰ ਨਾਲ ਵੇਖੋ।
MTTR ਘਟਾਉਣ ਲਈ, ਪਲੇਇਬੁੱਕ ਸਟੈਂਡਰਡ ਕਰੋ ਅਤੇ ਨਿਰਸਾਰ ਕੰਮਾਂ ਨੂੰ ਆਟੋਮੇਟ ਕਰੋ:
ਰਿਜ਼ੋਲੂਸ਼ਨ ਤੋਂ ਬਾਅਦ ਪੁੱਛੋ: “ਕਿਹੜਾ ਸਿਗਨਲ ਇਹ ਅਗਲੀ ਵਾਰੀ ਪਹਿਲਾਂ ਹੀ ਸਪਸ਼ਟ ਕਰਦਾ?” ਉਸ ਸਿਗਨਲ ਨੂੰ ਜੋੜੋ—Sysmon ਇਵੈਂਟ, ETW ਪ੍ਰੋਵਾਈਡਰ, ਇੱਕ ਪਰਫਾਰਮੈਂਸ ਕਾਜ਼, ਜਾਂ ਹਲਕਾ ਹੇਲਥ ਚੈਕ—ਤਾਂ ਜੋ ਅਗਲੀ ਵਾਰੀ ਇੰਸਿਡੈਂਟ ਛੋਟੀ ਤੇ ਸ਼ਾਂਤ ਹੋਵੇ।
Windows internals ਕੰਮ ਕਰਨ ਦਾ ਮਕਸਦ debugging ਜਿੱਤਣਾ ਨਹੀਂ—ਇਹ ਜੋ ਤੁਸੀਂ ਦੇਖਿਆ ਉਸਨੂੰ ਅਜਿਹੇ ਬਦਲਾਅ ਵਿੱਚ ਬਦਲਣਾ ਹੈ ਜੋ ਇੰਸਿਡੈਂਟ ਮੁੜ ਆਉਂਦੇ ਹੀ ਦੂਰ ਕਰ ਦੇਵੇ।
Internals ਟੂਲ ਅਕਸਰ ਸਮੱਸਿਆ ਨੂੰ ਕੁਝ ਹੀ ਲੀਵਰਾਂ ਤੱਕ ਘਟਾ ਦਿੰਦੇ ਹਨ। ਤਰਜਮਾ ਸਪਸ਼ਟ ਰੱਖੋ:
“ਕਿਉਂ” ਲਿਖੋ: “ਅਸੀਂ X ਬਦਲਿਆ ਕਿਉਂਕਿ ਅਸੀਂ Process Monitor / ETW / ਡੰਪ ਵਿੱਚ Y ਵੇਖਿਆ।” ਇਹ ਵਾਕ tribal knowledge ਨੂੰ ਫੈਲਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਤੁਹਾਡੀ ਬਦਲਾਅ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਫਲਾਉਣ ਵਾਲੇ ਖੇਤਰ ਨਾਲ ਮਿਲਾਓ:
ਭਾਵੇਂ ਮੂਲ ਕਾਰਨ ਵਿਸ਼ੇਸ਼ ਹੋ, ਟਿਕਾਊਪਣ ਅਮਲਕਾਰੇ ਰੀਯੂਜ਼ੇਬਲ ਪੈਟਰਨਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ:
ਜਿੰਨੀ ਲੋੜ ਹੈ ਰੱਖੋ, ਅਤੇ ਜੋ ਗ਼ਲਤ ਰਿਕਾਰਡ ਨਾ ਕਰੋ।
Procmon ਫਿਲਟਰ ਨੂੰ ਸੰਕੁਚਿਤ ਰੱਖੋ, ਸ਼ੇਅਰ ਕਰਦੇ ਸਮੇਂ ਪਾਥ/ਯੂਜ਼ਰਨੇਮ ਸਕ੍ਰੱਬ ਕਰੋ, ETW/Sysmon ਡੇਟਾ ਲਈ ਰਿਟੇਨਸ਼ਨ ਰੱਖੋ, ਅਤੇ ਜਰੂਰਤ ਤੋਂ ਬਾਹਰ ਨੈੱਟਵਰਕ ਪੇਲੋਡ ਕੈਪਚਰ ਕਰਨ ਤੋਂ ਬਚੋ।
ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਦੁਹਰਾਏ ਯੋਗ ਵਰਕਫਲੋ ਹੋਵੇ, ਅਗਲਾ ਕਦਮ ਇਸਨੂੰ ਪੈਕੇਜ ਕਰਨਾ ਹੈ ਤਾਂ ਕਿ ਹੋਰ ਲੋਕ ਵੀ ਇਸਨੂੰ ਇਕਸਾਰ ਚਲਾ ਸਕਣ। ਇਹ ਓਹੀ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਉਪਯੋਗੀ ਹੋ ਸਕਦਾ ਹੈ: ਤੁਸੀਂ ਆਪਣੀ ਇੰਸਿਡੈਂਟ ਚੈਕਲਿਸਟ ਨੂੰ ਇੱਕ ਛੋਟੀ ਆਉਟਰਨਲ ਵੈੱਬ ਐਪ (React UI, Go backend ਨਾਲ PostgreSQL) ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ ਜੋ responders ਨੂੰ “observe → capture → explain” ਰਾਹ ਨੂੰ ਮਾਰਗਦਰਸ਼ਿਤ ਕਰੇ, ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਆਰਟੀਫੈਕਟ ਸਟੋਰ ਕਰੇ, ਅਤੇ ਨਾਮਕਰਨ/ਕੇਸ-ਫਾਇਲ ਸਟੈਂਡਰਡ ਕਰੇ।
Koder.ai ਚੈਟ ਉਦਵਾਰਾ ਐਪ ਬਣਾਉਂਦੀ ਹੈ ਅਤੇ ਏਜੰਟ-ਅਧਾਰਤ ਆਰਕੀਟੈਕਚਰ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਇੱਤਰਤ ਕਰ ਸਕਦੀ ਹੈ—“start ETW session” ਬਟਨ, Procmon ਫਿਲਟਰ ਟੈਮਪਲੇਟ ਲਾਇਬ੍ਰੇਰੀ, snapshot/rollback ਬਟਨ, ਜਾਂ exportable runbook جنਰੈਟਰ ਦੇ ਨਾਲ—ਬਿਨਾਂ ਰਵਾਇਤੀ ਡੈਵ ਪਾਈਪਲਾਈਨ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੇ। Koder.ai ਸੋਰਸ-ਕੋਡ ਨਿਕਾਸ ਅਤੇ ਕਈ ਟੀਅਰ (ਫ੍ਰੀ ਤੋਂ ਐਨਟਰਪ੍ਰਾਈਜ਼) ਸਹਾਇਤਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ ਗਵਰਨੈਂਸ ਵਧਾ ਸਕਦੇ ਹੋ।
ਹਰ ਹਫ਼ਤੇ ਇੱਕ ਟੂਲ ਚੁਣੋ ਅਤੇ 15 ਮਿੰਟ ਦੀ ਅਭਿਆਸ ਕਰੋ: Procmon ਨਾਲ ਇੱਕ ਸੁਸਤ ਐਪ ਸਟਾਰਟ ਦਾ ਟ੍ਰੇਸ, Process Explorer ਵਿੱਚ ਇੱਕ ਸੇਵਾ ਟ੍ਰੀ ਦੇਖੋ, Sysmon ਇਵੈਂਟ ਵਾਲੀਊਮ ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਜਾਂ ਇੱਕ ਕ੍ਰੈਸ਼ ਡੰਪ ਲੈ ਕੇ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲਾ ਮੌਡੀਊਲ ਪਛਾਣੋ। ਛੋਟੀ ਅਭਿਆਸਾਂ ਮਾਸਲ ਮੈਮੋਰੀ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਅਸਲ ਇੰਸਿਡੈਂਟਾਂ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀਆਂ ਹਨ।
Mark Russinovich ਨੇ Windows troubleshooting ਦੇ ਲਈ ਇੱਕ ਸਬੂਤ-ਪਹਿਲਾਂ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਪ੍ਰਸਿੱਧ ਕੀਤਾ ਅਤੇ ਉਹਨਾਂ ਨੇ ਅਜਿਹੇ ਟੂਲਾਂ ਤੇ ਪ੍ਰਭਾਵ ਪਾਇਆ ਜੋ OS ਨੂੰ ਵਿਹਾਰਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਜੇ ਤੁਹਾਨੂੰ ਕਦੇ Windows Internals ਨਹੀਂ ਪੜ੍ਹਿਆ ਵੀ, ਤਾਂ ਵੀ ਤੁਸੀਂ Sysinternals, ETW ਅਤੇ ਡੰਪ ਵਿਸ਼ਲੇਸ਼ਣ ਨਾਲ ਬਣੇ ਵਰਕਫਲੋਜ਼ 'ਤੇ ਨਿਰਭਰ ਹੋ ਕੇ ਇੰਸਿਡੈਂਟ ਛੋਟੇ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਬਣਾ ਸਕਦੇ ਹੋ।
ਨਿਰੀਖਣਯੋਗਤਾ ਉਹ ਸਮਰੱਥਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਸਿਸਟਮ ਸੰਕੇਤਾਂ ਤੋਂ ਹੁਣੇ-ਹੁਣੇ ਪੁੱਛ ਸਕਦੇ ਹੋ “ਹੁਣ ਕੀ ਹੋ ਰਿਹਾ ਹੈ?”
Windows 'ਤੇ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਤਰ੍ਹਾਂ ਦੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਜੋੜ ਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:
Internals ਦਾ ਗਿਆਨ ਤੁਹਾਨੂੰ ਅਸਪਸ਼ਟ ਲੱਛਣਾਂ ਨੂੰ ਜਾਂਚਣ ਯੋਗ ਪਰਿਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਉਦਾਹਰਣ ਲਈ, “ਸਰਵਰ ਧੀਮਾ ਹੈ” ਨੂੰ ਤੁਸੀਂ ਸਨੁਨ, paging ਦਬਾਅ, I/O ਦੀਰੀ, ਜਾਂ ਡਰਾਈਵਰ/ਫਿਲਟਰ ਓਵਰਹੈੱਡ ਵੱਲ ਦਰਜ ਕਰਕੇ ਤੇਜ਼ੀ ਨਾਲ ਟਰਿਆਜ ਕਰ ਸਕਦੇ ਹੋ। ਇਸ ਨਾਲ ਸਬੂਤ ਇਕੱਤਰ ਕਰਨ ਅਤੇ ਸਹੀ ਫਿਕਸ ਲਗਾਉਣ ਵਿੱਚ ਸਮਾਂ ਘੱਟ ਹੁੰਦਾ ਹੈ।
Process Explorer ਨੂੰ Task Manager ਨਾਲੋਂ ਵੱਧ ਜਾਣਕਾਰੀ ਲਈ ਵਰਤੋ।
ਇਹ ਤੇਜ਼ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਲਈ ਵਧੀਆ ਹੈ:
Process Monitor ਉਦੋਂ ਵਰਤੋ ਜਦ ਤੁਹਾਨੂੰ ਫ਼ਾਇਲ, ਰਜਿਸਟਰੀ ਅਤੇ ਪ੍ਰੋਸੈਸ/ਥ੍ਰੈਡ ਕਾਰਵਾਈਆਂ ਦਾ ਪੂਰਾ ਟਰੇਲ ਚਾਹੀਦਾ ਹੋਵੇ।
ਵਿਹਾਰਕ ਉਦਾਹਰਣ:
Procmon ਦਾ ਹੁਸ਼ਿਆਰ ਫਿਲਟਰਿੰਗ ਕਰਕੇ ਰਿਕਾਰਡਿੰਗ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਵਿਫਲਤਾ ਦੇ ਖਿੜਕੀ ਵਾਰ ਰਿਕਾਰਡ ਕਰੋ।
ਅੱਛੀ ਸ਼ੁਰੂਆਤੀ ਵਰਕਫਲੋ:
ਛੋਟਾ ਤੇ ਵਿਸ਼ਲੇਸ਼ਣਯੋਗ ਟਰੇਸ ਵੱਡੇ ਬੇਕਾਰ ਲੋਗ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਜਿਆਦਾ ਮੁੱਲ ਵਾਲਾ ਹੁੰਦਾ ਹੈ।
Autoruns ਦੱਸਦਾ ਹੈ “ਆਪਣੇ ਆਪ ਕੀ ਚੱਲਦਾ ਹੈ?”—ਸੇਵਾ, ਨਿਯਤ ਕਾਰਜ, ਡਰਾਈਵਰ, ਸ਼ੈੱਲ ਐਕਸਟੈਂਸ਼ਨ ਆਦਿ।
ਇਹ ਖਾਸ ਕਰਕੇ ਫਾਇਦੇਮੰਦ ਹੈ:
ਪਹਿਲਾਂ ਉਹ ਐਂਟਰੀਜ਼ ਦੇਖੋ ਜੋ unsigned, ਹਾਲ ਹੀ ਵਿੱਚ ਜੋੜੀਆਂ ਗਈਆਂ, ਜਾਂ ਹਨ; ਇੱਕ-ਇੱਕ ਕਰਕੇ ਡਿਸੇਬਲ ਕਰਦੇ ਹੋਏ ਨੋਟ ਲਵੋ।
ETW (Event Tracing for Windows) Windows ਦਾ ਉੱਚ-ਵੋਲਿਊਮ, ਸਟ੍ਰੱਕਚਰਡ ਟ੍ਰੇਸਿੰਗ ਸਿਸਟਮ ਹੈ।
ਜਦ ਲੌਗ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਦੱਸਦੇ ਹਨ ਕਿ ਕੁਝ ਠੀਕ ਨਹੀਂ ਹੈ ਪਰ ਕਾਰਨ ਨਹੀਂ ਦੱਸਦੇ, ਉਦੋਂ ETW ਵਰਤੋਂ—ਉਦਾਹਰਣ ਲਈ I/O ਦੇਰੀ, ਸ਼ੈਡਿਊਲਿੰਗ ਦੇਰੀਆਂ, ਡਰਾਈਵਰ ਵਿਹਾਰ ਜਾਂ ਨਿਰਭਰਤਾ ਟਾਈਮਆਊਟ।
ਹਮੇਸ਼ਾ “ਸਭ ਕੁਝ ਹਮੇਸ਼ਾਂ ਲਈ ਚਾਲੂ” ਨਾ ਰੱਖੋ; ਛੋਟੇ, ਨਿਸ਼ਾਨੇਵੰਦ ETW ਕੈਪਚਰ ਇੰਸਿਡੈਂਟ ਦੌਰਾਨ ਵਰਤੋਂ।
Sysmon ਉੱਚ-ਸੰਦਰਭ ਟੇਲੀਮੇਟਰੀ ਦਿੰਦਾ ਹੈ (parent/child ਪ੍ਰੋਸੈਸ, ਕਮਾਂਡ ਲਾਈਨ, ਹੈਸ਼, ਡਰਾਈਵਰ ਲੋਡ) ਜੋ ਇਹ ਸਵਾਲ ਤੁਹਾਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ “ਹੁਣ ਕੀ ਬਦਲਿਆ?”
ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਇਹ ਮਦਦਗਾਰ ਹੈ:
ਹਮੇਸ਼ਾ ਇੱਕ ਨਰੈਲ/ਸੀਮਤ ਕਾਨਫਿਗ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਖਾਲੀ ਹੀਰੇ/ਬਾਹਰ ਦੇ ਨੀਯਮ ਲਗਾ ਕੇ ਘਟਨਾ ਦੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਸੰਭਾਲੋ।
ਡੰਪ ਇਕ ਮਹੱਤਵਪੂਰਨ ਆਰਟੀਫੈਕਟ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਯਾਦਾਂ ਅਤੇ ਐਕਜ਼ੈਕਿਊਸ਼ਨ ਸਟੇਟ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਜੋ ਨੁਕਸਾਨ ਦੇ ਸਮੇਂ ਕੀ ਹੋ ਰਿਹਾ ਸੀ ਨੂੰ ਮੁੜ ਬਣਾਉਂਦਾ ਹੈ।
WinDbg ਡੰਪ ਨੂੰ ਕਹਾਣੀ ਵਿੱਚ ਬਦਲਦਾ ਹੈ: symbols ਲੋਡ ਕਰਨਾ, স্টੈਕ ਚੈੱਕ ਕਰਨਾ, ਅਤੇ ਅਸਲ ਫੇਲਿੰਗ ਕੰਪੋਨੈਂਟ ਦੀ ਪਛਾਣ ਕਰਨਾ ਮੂਲ ਸੂਤਰ ਹਨ।
