Tăng đột biến mức sử dụng CPU cao theo hệ thống hoặc svchost.exe – Hướng dẫn kỹ thuật từng bước

Việc CPU tăng đột biến từ System hoặc svchost.exe có thể biến bất kỳ ngày nào thành cơn ác mộng, vì máy tính trở nên chậm chạp, quạt kêu to và mọi thứ dường như bị giật. Tin tốt là, với một phương pháp tiếp cận có cấu trúc, bạn có thể xác định dịch vụ, nhà cung cấp hoặc ứng dụng nào gây ra vấn đề và áp dụng giải pháp hiệu quả.

Trong hướng dẫn thực hành này, tôi sẽ hướng dẫn bạn từng bước một, từ việc xác định tiến trình thực sự tiêu tốn nhiều CPU (System, svchost.exe hoặc WmiPrvse.exe) đến việc cô lập các truy vấn WMI gây ra sự cố, tách các dịch vụ, đo mức sử dụng CPU bằng Perfmon, kiểm tra trình điều khiển và giải quyết các nguyên nhân phổ biến như gián đoạn hệ thống, phần mềm độc hại hoặc cấu hình lỗi thời. Mục tiêu là chuyển từ câu hỏi "Tại sao nó lại chiếm 100% CPU?" sang "Tôi biết chính xác nguyên nhân và cách khắc phục nó."

Xác định quy trình chính xác và PID của nó

Bước đầu tiên là phải tìm ra tệp nhị phân và PID nào đang chiếm dụng CPU, và liệu thủ phạm thực sự là WmiPrvse.exe (máy chủ cung cấp WMI), svchost.exe (chứa Winmgmt/WMI), hay chính hệ thống (các ngắt hệ thống và hạt nhân).

Từ Trình quản lý tác vụ, hãy chuyển đến tab Chi tiết và sắp xếp theo Tên hoặc CPU. Tìm WmiPrvse.exe hoặc svchost.exe có mức sử dụng tài nguyên cao và ghi lại PID của nó. Trong mục Dịch vụ (trong Trình quản lý tác vụ), tìm Winmgmt, ghi lại PID của nó và sử dụng Chuyển đến Chi tiết để chuyển đến svchost.exe đang chạy nó. Điều này sẽ cho thấy rõ ràng phiên bản cụ thể nào đang tiêu tốn nhiều tài nguyên.

Hãy quan sát mô hình sử dụng: có những đợt tăng đột biến thường xuyên, mức tiêu thụ liên tục, sử dụng ngẫu nhiên, chỉ sử dụng trong giờ làm việc, hoặc khi đăng nhập/đăng xuất? Những chi tiết này vô cùng quan trọng để đối chiếu với các tác vụ, tập lệnh, công cụ giám sát hoặc ứng dụng của bên thứ ba kích hoạt WMI.

Đo lường và tương quan với Performance Monitor (Perfmon)

Perfmon cho phép bạn đối chiếu PID với hình ảnh đồ họa về phần trăm sử dụng CPU, và phân biệt chính xác tiến trình WmiPrvse.exe hoặc svchost.exe nào đang tiêu thụ tài nguyên.

1. Mở một nhắc lệnh được nâng lên và thực hiện perfmon. Chọn Performance Monitor và nhấn nút + để Thêm Bộ đếm.
2. Thêm bộ đếm "Process \ Process Id" và chọn tất cả các phiên bản WmiPrvse# (hoặc svchost# nếu có). Các giá trị Last/Average/Minimum/Maximum phản ánh PID: xóa bất kỳ giá trị nào không khớp với PID mà bạn đang nhắm đến bằng lệnh Del.
3. Bây giờ thêm "Process \ % Processor Time" trên trường hợp chính xác (ví dụ: WmiPrvse#1) khớp với PID nóng và quan sát đường cong tiêu thụ theo thời gian thực.

Svchost.exe có nhiều dịch vụ không? Kiểm tra xem những yếu tố nào ảnh hưởng đến WMI của bạn: tasklist /svc /fi "Services eq Winmgmt"Nếu bạn muốn tách WMI trong quy trình riêng của nó để chẩn đoán tốt hơn hoặc hạn chế tác động, hãy sử dụng:

sc config Winmgmt type= own
net stop winmgmt && net start winmgmt

Khi bạn giải quyết được sự cố, bạn có thể đưa sự cố trở lại quy trình chia sẻ. với sc config Winmgmt type= share và khởi động lại dịch vụ WMI.

Kiểm tra quy trình từ bên trong: Các nguồn lực và nhà cung cấp WMI

Đừng chỉ tập trung vào CPU: hãy kiểm tra Bộ nhớ, Mã định danh, Luồng và Người dùng PID trong tab Chi tiết của Trình quản lý tác vụ. Nếu có hiện tượng rò rỉ handle hoặc nhiều luồng, điều đó củng cố giả thuyết về một nhà cung cấp hoặc máy khách WMI hoạt động không hiệu quả.

Xác định các nhà cung cấp WMI (DLL) được tải trong WmiPrvse.exe cụ thể, Ví dụ, với Process Explorer (chạy với quyền quản trị viên): mở thuộc tính của WmiPrvse.exe với PID bạn đang điều tra và trong tab Nhà cung cấp, bạn sẽ thấy các chi tiết như Tên Nhà cung cấp, Không gian tên và đường dẫn DLL. Một trường hợp điển hình là MS_NT_EVENTLOG_PROVIDER trong root\CIMV2 với DLL %systemroot%\system32\wbem\ntevt.dllĐể biết thêm các kỹ thuật, hãy xem Phân tích các truy vấn theo lịch trình và nhà cung cấp trong WMI.

Nếu vấn đề không liên tục và WmiPrvse.exe được tái chế, bạn có thể nhanh chóng xác định vị trí phiên bản chứa DLL cụ thể bằng: tasklist /m <Proveedor.dll>. Ví dụ: tasklist /m ntevt.dll.

Kiểm tra các truy vấn đến WMI (Trình xem sự kiện)

Nhật ký Microsoft-Windows-WMI-Activity giống như radar của bạn, vì nó phản ánh mọi hoạt động WMI đến và cho bạn biết truy vấn nào đã được gửi đến, từ PID máy khách nào, với người dùng nào và nhắm vào lớp/không gian tên nào.

Kích hoạt và xem xét hai nguồn nhật ký: Nhật ký vận hành và Nhật ký phân tích/gỡ lỗi. Trong Trình xem sự kiện, hãy vào Nhật ký ứng dụng và dịch vụ > Microsoft > Windows > Hoạt động WMI. Trên menu Xem, chọn "Hiển thị nhật ký phân tích và gỡ lỗi" và bật tính năng ghi nhật ký trong mục Theo dõi và Gỡ lỗi. Giữ cho chúng hoạt động trong khi ghi lại sự tăng đột biến CPU, sau đó xuất sang định dạng .csv hoặc .xml.

Các sự kiện chính và cách đọc chúng: Id. 11 (Ví dụ: Bắt đầu hoạt động) IWbemServices::ExecQuery o CreateInstanceEnum) và ID 12 (ProviderInfo, ánh xạ thao tác đến HostId/PID và DLL của nhà cung cấp). Trong phần mô tả, bạn sẽ thấy các trường như CorrelationId, GroupOperationId, OperationId, Operation, ClientMachine, User, ClientProcessId, NamespaceName và chính truy vấn, ví dụ: select * from Win32_Product o CreateInstanceEnum - root\cimv2 : Win32_NTLogEvent.

Với một vài bộ lọc trên lớp (ví dụ: "Win32_NTLogEvent") và HostId/PID, Bạn sẽ có thể liệt kê các chuỗi theo kiểu: Bắt đầu của CreateInstanceEnum ngược lại Win32_NTLogEvent từ PID máy khách 5484, được ánh xạ tới MS_NT_EVENTLOG_PROVIDER trên HostId 556 (WmiPrvse.exe nóng của bạn) có DLL là ntevt.dllTham chiếu chéo này cuối cùng cung cấp cho bạn quy trình máy khách tạo ra tải.

WMIMon: Giám sát trực tiếp các cuộc gọi WMI

Nếu bạn muốn xem nhanh chóng và trực tiếp ai đang gọi WMI và tần suất gọi như thế nào, công cụ công khai WMIMon.exe (dự án "luctalpe/WMIMon" trên GitHub) rất hữu ích để liệt kê PID, Namespace, Class và User của Client cho mỗi thao tác.

1. Tải WMIMon và chạy nó ở chế độ nâng cao, tốt nhất là sau khi xác định WmiPrvse.exe chiếm nhiều CPU, để nắm bắt được thời điểm quan trọng.
2. Hãy để nó thu thập hoạt động WMI vài phút và phân tích PID nào được truy vấn trong vòng lặp và lớp nào (mô hình điển hình của các đầu dò hoặc tập lệnh giám sát được thiết kế kém).

Nếu bạn không thể khoanh vùng nguyên nhân đến một ứng dụng cụ thể, hãy nhóm theo tài khoản người dùng hoặc thiết bị nguồn; thường thì đó là tài khoản dịch vụ được liên kết với công cụ kiểm kê, SCCM ( PolicyAgent/MonitoringHost ) hoặc các tập lệnh PowerShell truy vấn quá thường xuyên hoặc với khoảng thời gian quá ngắn.

Các hành động khắc phục đối với WMI và các dịch vụ liên quan

Khi đã bắt được nghi phạm, trước tiên hãy áp dụng các biện pháp không phá hủy: Tạm thời vô hiệu hóa dịch vụ cho ứng dụng đó, dừng tác nhân giám sát hoặc sửa lỗi kịch bản (truy vấn các thuộc tính cụ thể, sử dụng bộ lọc, tăng phạm vi, tránh các lớp có vấn đề như Win32_Product (chậm). Xem CPU có giảm không.

Nếu svchost.exe nhóm quá nhiều dịch vụ và khiến bạn khó có thể cô lập, để Winmgmt trong quá trình riêng của mình với sc config Winmgmt type= own, khởi động lại WMI và lặp lại các phép đo. Điều này giới hạn bán kính nổ và giúp chẩn đoán dễ dàng hơn. Để tìm hiểu sâu hơn về tối ưu hóa, hãy xem cải thiện hiệu suất WMI.

Để được hỗ trợ nâng cao từ Microsoft, Bạn có thể ghi lại mọi thứ bằng gói TSS (Bộ tập lệnh khắc phục sự cố) chạy trong PowerShell nâng cao: .\TSS.ps1 -UEX_WMIBase -WIN_Kernel -ETWflags 1 -WPR CPU -Perfmon UEX_WMIPrvSE -PerfIntervalSec 1 -noBasicLog. Sau khi hoàn tất, một tệp ZIP chứa ETW, Perfmon, WPR và nhiều nội dung khác sẽ được tạo, sẵn sàng để tải lên.

Hệ thống và Ngắt hệ thống: Khi hạt nhân tăng hóa đơn

Nếu tiến trình "Hệ thống" (ngắt hệ thống) dao động quanh mức 5-10% hoặc tăng đột biến, rất có thể đó là vấn đề về trình điều khiển hoặc phần cứng (DPC và độ trễ). Cách tiếp cận sẽ thay đổi ở đây: bạn cần chẩn đoán độ trễ của trình điều khiển và thiết bị.

Hãy bắt đầu với DPC Latency Checker và LatencyMon: công cụ đầu tiên sẽ cảnh báo bạn về các đỉnh độ trễ của nhân hệ điều hành; công cụ thứ hai cho bạn biết trình điều khiển nào (ví dụ: âm thanh, mạng, lưu trữ , USB) đang tạo ra các DPC kéo dài. Nếu bạn thấy các thanh màu đỏ hoặc các trình điều khiển được tô sáng, bạn đang đi đúng hướng.

Tắt từng thành phần nghi ngờ một từ Trình quản lý thiết bị , tạm thời vô hiệu hóa bộ điều hợp mạng, âm thanh tích hợp, card thu hình, hub PCI/PCIe/USB, v.v. Quan sát tác động của "Ngắt hệ thống" lên CPU. Kích hoạt lại những thành phần không bị ảnh hưởng và tiếp tục lặp lại cho đến khi tìm ra thủ phạm.

Ngắt kết nối từng thiết bị ngoại vi (bao gồm cả hub USB) một trong khi theo dõi Trình quản lý tác vụ. Nếu việc này gây khó khăn, hãy vô hiệu hóa hub USB từ Trình quản lý thiết bị (hãy cẩn thận nếu chuột/bàn phím của bạn phụ thuộc vào chúng: hãy chuẩn bị sẵn một thiết bị điều khiển từ xa khác).

Đừng loại trừ khả năng phần cứng bị hỏng hoặc nguồn điện không ổn định: nguồn điện bị lỗi hoặc bộ sạc máy tính xách tay bị hỏng có thể gây ra hiện tượng tăng đột biến IRQ/DPC. Đôi khi giải pháp duy nhất là thay thế tạm thời và kiểm tra.

Hãy thử tắt hiệu ứng âm thanh trong các phiên bản Windows cũ hơn (ví dụ: Windows 7), vì đôi khi chúng gây ra sự cố về độ trễ: Bảng điều khiển âm thanh > Thiết bị phát lại > Thuộc tính loa > tab Hiệu ứng > Tắt hiệu ứng.

Hãy cập nhật BIOS/UEFI và kiểm tra phiên bản trước khi cập nhật: mở ra CMD và chạy systeminfo | findstr /I /c:bios y wmic bios get manufacturer, smbiosbiosversion. Sau đó, hãy làm theo quy trình của nhà sản xuất một cách hết sức cẩn thận để tránh làm hỏng bo mạch.

Các biện pháp chung để kiểm soát sự tăng đột biến của CPU

• Đóng các ứng dụng bạn không sử dụng và tránh thực hiện nhiều tác vụ cùng lúc, Đặc biệt nếu bạn có hàng chục tab hoặc tiến trình đang chạy ở chế độ nền; hãy giải phóng tài nguyên và xem CPU của bạn có giảm xuống dưới 90-100% không.
• Loại trừ phần mềm độc hại bằng cách quét toàn bộ và cập nhật, Vì phần mềm quảng cáo, trình đào tiền ảo và sâu máy tính thường chiếm dụng CPU nên hãy quét cả hệ thống và ổ đĩa ngoài.
• Cập nhật trình điều khiển và phần mềm dễ bị lỗi, đặc biệt là mạng, âm thanh và đồ họa. Trình điều khiển Wi-Fi lỗi thời có thể đủ để làm quá tải CPU sau khi cập nhật Windows.
• Điều chỉnh công suất để tránh hiện tượng điều chỉnh nhiệt hoặc giới hạn không cần thiết, sử dụng một kế hoạch cân bằng và nếu bạn cần giảm nhiệt tại chỗ, hãy giới hạn "Trạng thái bộ xử lý tối đa" ở mức 90% từ Tùy chọn nguồn nâng cao.
• Giảm tiếng ồn từ thông báo và các tiến trình nền trong Windows, vô hiệu hóa các thông báo không đóng góp và Tối ưu hóa phân phối (Windows Update > Tùy chọn nâng cao > Tối ưu hóa phân phối > Cho phép tải từ các thiết bị khác: Đã tắt).
• Nếu bạn không sử dụng Cortana, bạn có thể vô hiệu hóa dịch vụ trợ giúp của nó trong Registry, đi vào HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TokenBroker và thiết lập Start en 4 (vui lòng sao lưu sổ đăng ký trước).
• Khởi động lại WMI Provider Host (Winmgmt) khi nó bị treo, Từ Dịch vụ: Tìm kiếm “Windows Management Instrumentation” và nhấn Khởi động lại, sau đó xác nhận xem mức sử dụng CPU có giảm không.
• Đừng quên bảo trì vật lý: Bụi trên quạt và bộ tản nhiệt làm tăng nhiệt độ và CPU tự bảo vệ bằng cách giảm tần số; hãy vệ sinh bằng khí nén và kiểm tra luồng không khí.

svchost.exe (Máy chủ dịch vụ: Hệ thống cục bộ) tiêu tốn CPU

svchost.exe là một dịch vụ chứa chứ không phải là một chương trình độc lập, vì vậy hiện tượng tăng đột biến thường là do một trong các dịch vụ được lưu trữ (Windows Update, WMI, mạng, v.v.).

Để xác định dịch vụ cụ thể: Trong Trình quản lý tác vụ > Quy trình, hãy mở rộng "Máy chủ dịch vụ: Hệ thống cục bộ" và xem mức sử dụng theo dịch vụ; hoặc sử dụng tasklist /svc và so khớp PID với các dịch vụ. Nếu WMI là thủ phạm, hãy quay lại phần chẩn đoán WMI.

Các bước khắc phục thông thường bao gồm: khởi động lại máy tính, chạy phần mềm diệt virus, cập nhật trình điều khiển, chạy Windows Update, tạm thời tắt các dịch vụ không cần thiết (cần thận trọng) và kiểm tra chế độ quản lý năng lượng. Việc giữ cho hệ thống và ứng dụng luôn được cập nhật sẽ giảm thiểu các sự không tương thích gây ra hiện tượng giảm hiệu năng đột ngột.

Để phòng ngừa, hãy sử dụng các công cụ giám sát để phát hiện các đột biến bất thường, thiết lập cập nhật tự động, tránh tải xuống các tệp đáng ngờ và thực hiện dọn dẹp và chống phân mảnh khi cần thiết.

Môi trường doanh nghiệp và VDI (Citrix): Những cân nhắc

Nếu môi trường của bạn là Citrix (XenApp/XenDesktop/StoreFront/PVS), hãy lưu ý rằng có một số sự cố đã biết có thể ảnh hưởng đến tính ổn định, mức tiêu thụ tài nguyên và trải nghiệm phiên làm việc. Mặc dù đây không phải là nguyên nhân điển hình gây ra hiện tượng tăng đột biến liên quan đến System/svchost.exe, nhưng vẫn đáng để bạn biết đến chúng.

Ví dụ về các khu vực bị ảnh hưởng được trích dẫn trong ghi chú phát hành: Citrix Studio (cấp phép, xuất bản với dấu ngoặc kép, giải quyết tên miền, chậm với bộ điều khiển bị ngắt kết nối, App-V có ApplicationID trùng lặp, vòng lặp cập nhật, sự cố khi thêm Bộ điều khiển phân phối/phản chiếu SQL); Dịch vụ cung cấp (trình hướng dẫn với SCVMM/ESX, sao chép vDisk, thời gian chờ SOAP do tên miền không thể truy cập, danh sách đen tên miền trong %ProgramData%\Citrix\Provisioning Services\blacklist.json); StoreFront (màu thư mục, sập khi tùy chỉnh CSS, xác thực liên kết, tự phục vụ, kết nối lại nhiều trang web); VDA/Receiver (Framehawk, clipboard, khóa màn hình, âm thanh, nhiều màn hình, kênh ảo, SDK); App-V tích hợp (đồng bộ hóa, ký tự đặc biệt trong tên, xuất bản từ ổ đĩa được ánh xạ).

Các khuyến nghị nhanh trong Citrix: duy trì các phiên bản được hỗ trợ, xem xét các bản vá lỗi (ID theo kiểu LCxxxx), xác thực App-V và SCCM trong môi trường thử nghiệm, giám sát VDA và Delivery Controller sau khi thay đổi, và ghi lại mối tương quan về thời gian giữa các đỉnh CPU và các tác vụ của Citrix (cập nhật danh mục, MCS/PVS, Director, v.v.).

Khi nào CPU 100% là “bình thường” và khi nào thì không?

Việc xử lý video, biên dịch phần mềm hoặc cài đặt các bản cập nhật lớn có thể khiến mức sử dụng CPU tạm thời tăng lên 90-100%, và điều này là bình thường nếu sau đó mức sử dụng giảm xuống dưới 10% khi ở trạng thái rảnh rỗi hoặc xuống 10-30% khi sử dụng nhẹ. Nếu mức sử dụng CPU duy trì ở mức 100% trong thời gian dài mà không có tác vụ nào chính đáng, cần phải can thiệp.

Nếu bạn đã làm đến bước này, bạn đã có một lộ trình hoàn chỉnh: xác định PID và tiến trình thực tế, đo lường và đối chiếu với nhật ký Perfmon và WMI, xác định nhà cung cấp và máy khách, thực hiện các hành động khắc phục (tối ưu hóa truy vấn, phân chia dịch vụ, điều chỉnh trình điều khiển và nguồn điện), giải quyết các nguyên nhân phổ biến (phần mềm độc hại, bụi bẩn, thiết bị ngoại vi), và trong môi trường doanh nghiệp, hãy ghi nhớ các đặc thù của Citrix và App-V. Với phương pháp và sự kiên nhẫn, những sự cố tăng đột biến đó sẽ không còn là bí ẩn và sẽ được kiểm soát.