Cảnh báo WAN Miniport: sửa bộ điều hợp hoặc dựng lại hồ sơ

Bị treo trước khi thông tin đăng nhập được đưa ra, từ chối xóa hồ sơ, hiển thị một bộ điều hợp mà không ai nhận ra tên: đó là ba gương mặt của cùng một lỗi. Giao diện phần mềm mà VPN gắn vào đã hỏng, trong khi tài khoản và cổng vào vẫn nguyên vẹn. Ba cách sửa là hợp lý, và cách nào áp dụng được suy ra từ một lần kiểm tra chỉ đọc. Mọi thứ sau lần kiểm tra đó là số học; mọi thứ trước đó là phỏng đoán.

Hồ sơ thực sự gắn vào cái gì

Mỗi loại đường hầm gốc của Windows được phục vụ bởi bộ điều hợp ảo riêng, và những bộ điều hợp đó là trình điều khiển miniport chứ không phải card vật lý. Hồ sơ chọn một loại đường hầm, loại đó chọn một bộ điều hợp, vì vậy một trình điều khiển không khỏe có thể làm hỏng mọi hồ sơ dùng chung nó trong khi chia sẻ tệp và duyệt web vẫn tiếp tục. Sự phụ thuộc này vô hình trong thuộc tính hồ sơ.

Những giao diện này mặc định bị ẩn, cả trong Trình quản lý thiết bị lẫn trong danh sách bộ điều hợp. Đó là cách một cái hỏng vẫn vô hình trong khi chủ máy khẳng định không có gì thay đổi.

Dấu cảnh báo là bằng chứng hữu ích còn biểu tượng sạch thì không. Bộ điều hợp có thể báo cáo mình khỏe mạnh mà vẫn mang một liên kết hỏng, nên câu hỏi hữu ích là giao diện được gắn vào cái gì, không phải biểu tượng trông thế nào. Hãy đọc trạng thái trước và các liên kết sau, vì biểu tượng trả lời câu hỏi kém thú vị nhất. Bỏ qua thứ tự đó chính là điều biến một lần kiểm tra mười phút thành cả buổi chiều làm việc với trình điều khiển.

Quyết định dựa trên trạng thái bộ điều hợp, không phải mã lỗi

Một số lỗi cho biết giai đoạn nào thất bại và không nói gì về việc thành phần nào có lỗi. Cấp phát địa chỉ, chọn chứng chỉ và giao thức đường hầm có số riêng, theo quy ước là 720, 789 và 806, và không số nào trong ba số đó là bằng chứng về miniport. Dùng con số để chọn lần kiểm tra tiếp theo, không phải để chọn cách sửa.

Các quan sát phân biệt được thì ít. Bảng này ánh xạ từng quan sát sang một bước tiếp theo chỉ đọc:

Thứ tự quan trọng vì cài lại trình điều khiển thì chậm và gây gián đoạn. Làm việc đó để sửa một vấn đề cấp phát tốn một giờ và không dạy được gì cho người tiếp theo. Bảng cũng xác định bán kính hư hại: một giao thức hỏng trên mọi hồ sơ chỉ vào trình điều khiển, trong khi một ứng dụng khách của nhà cung cấp hỏng bên cạnh các hồ sơ gốc đang chạy chỉ vào chồng của nhà cung cấp.

Hai lần đọc giải quyết phần lớn phiếu

Cả hai lần đọc đều chỉ đọc và không lần nào chạm vào trình điều khiển. Lần đầu liệt kê các giao diện miniport ẩn cùng trạng thái, lần thứ hai liệt kê bộ điều hợp có tên được gắn vào cái gì:

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -like 'WAN Miniport*' | Select-Object Name, InterfaceDescription, Status
Get-NetAdapterBinding -Name 'WAN Miniport (IKEv2)' -IncludeHidden -AllBindings

Hãy thay bằng giao thức mà hồ sơ của bạn dùng, vì danh sách liên kết cho IKEv2 không nói gì về một SSTP hồ sơ. Một liên kết ARP hoặc IPv4 bị tắt, hoặc một trình điều khiển lọc của bên thứ ba gắn vào bộ điều hợp, có thể dừng đường hầm trước khi nó bắt đầu. Việc phần mềm bảo mật xuất hiện trong danh sách đó không chứng minh nó là nguyên nhân, nên hãy xác lập tác động trước khi tắt bất cứ thứ gì.

Một bộ điều hợp khỏe mạnh hiển thị các liên kết bạn mong đợi và không có bộ lọc nào bạn không giải thích được. Khi danh sách sạch, bằng chứng đã chuyển sang chính trình điều khiển và phần tiếp theo là phần áp dụng được.

Lưu tên bộ điều hợp và phiên bản trình điều khiển trước khi gỡ nó

Khi bộ điều hợp thực sự không dùng được, cách sửa tiêu chuẩn là làm cho nó có thể gỡ bỏ, gỡ cài đặt và để Windows tạo một phiên bản mới vào lần tới khi một hồ sơ dùng giao thức đó. Trong Trình quản lý thiết bị, cập nhật trình điều khiển, chọn từ danh sách, xóa bộ lọc phần cứng tương thích và chọn một bộ điều hợp Microsoft chung có tùy chọn gỡ cài đặt.

Trước đó, hãy ghi lại những gì bạn đang xóa: tên bộ điều hợp, phiên bản trình điều khiển, nhà cung cấp và ngày. Một cách sửa mà sau này bạn không mô tả được thì không thể lặp lại, và cái giá thông thường của một lần sửa không mô tả là cùng chiếc máy được sửa ba lần. Tiện ích của nhà cung cấp làm cùng công việc với phạm vi rộng hơn và hợp lý trong một đội máy được quản lý khi chúng đến từ nhà cung cấp chứ không phải từ bản sao gương. Một tiện ích thay thế các tệp nhị phân của trình điều khiển thay đổi nhiều hơn việc cài lại một bộ điều hợp, nên hãy ghi cả phiên bản của nó vào phiếu.

Một trường hợp của nhà cung cấp cần cách sửa khác cho cùng triệu chứng. Một ứng dụng khách đăng ký bộ điều hợp của mình dưới một tên hiển thị có chứa tham chiếu trình cài đặt có thể không bật được sau khi nâng cấp, và bản sửa sẽ chỉnh sửa tên đó trong một khóa dịch vụ thuộc nhà cung cấp. Giá trị nhận một tên bộ điều hợp thông thường, và ứng dụng khách được khởi động lại sau đó:

HKLM\SYSTEM\CurrentControlSet\Services\CVirtA
DisplayName = Cisco Systems VPN Adapter for 64-bit Windows

Khóa đó thuộc về một ứng dụng khách duy nhất. Đây không phải là cách sửa Windows chung và không bao giờ được áp dụng cho một máy không chạy ứng dụng khách đó.

Xác nhận bằng giao thức thứ hai trước khi đóng phiếu

Một lần kết nối lại thành công chỉ thử một giao thức qua một bộ điều hợp, nên nó chứng minh ít hơn vẻ ngoài. Hãy thử lại hồ sơ gốc, rồi một hồ sơ thứ hai dựng trên loại đường hầm khác, và yêu cầu cả hai đều kết nối. Nếu chỉ cái đầu tiên hoạt động, lỗi còn lại là bằng chứng về trình điều khiển hoặc chính sách chứ không phải về giao diện bạn vừa dựng lại.

Nếu khiếu nại ban đầu là một hồ sơ không thể xóa, hãy thử lại điều đó nữa, vì một hồ sơ vẫn từ chối bị xóa sau khi bộ điều hợp đã khỏe là một lỗi khác và mọi công việc thêm trên bộ điều hợp là lãng phí. Giữ tài khoản và cổng vào ra khỏi biên bản trừ khi có gì đó chỉ vào chúng. Một đường hầm chết trước khi xác thực thường mô tả chiếc máy, và một ghi chú trung thực nêu tên bộ điều hợp, giao thức và lần kiểm tra đã xác nhận điều đó.