Repository navigation
Npcap 0.9989 install gets stuck and does not complete #1996
Description
While upgrading from an older version of Wireshark to 3.2.3 the npcap-0.9989.exe installer ran. I checked the box stating I wanted to install the driver to work with wireless network adapters (since I have a laptop).
The Wireshark installation has been stuck for 30 minutes saying "Identify the wireless adapters and write them into the registry" above the progress bar. In the detailed installation logs at the bottom the last entry is "Wlan adapters have been successfully written to registry!".
From this point, no progress has happened in the installation and it is stuck.
Reacted by Scott Harvey and Jaepil.Choi
Activity
OscarVanL commentedon Apr 9, 2020
I killed a process consuming around 15% CPU in task manager and now Npcap's installation has been completed, supposedly with no errors.
However after rebooting and launching Wireshark, the only interfaces detected is USBcap1.
Please also be aware I had WinPcap for Fing 4.1.3 installed in addition to Wireshark when updating.
Upon trying to uninstall Npcap I was presented with this error. Perhaps the initial installation failure was caused because fingagent.exe was running when upgrading Wireshark?
When then going to reinstall Wireshark I am presented with this window, which further reinforces this suspicion.
sctthrvy commentedon Apr 26, 2020
I have the same issue. The 0.9989 Npcap installer hangs forever during the install of Wireshark-Win64-3.2.3. I am running Windows 10 version 1909, build 18363.778.
During this time I took a WPR trace for ~70 seconds and looked at what was happening using WPA.
NPFInstall.exe is stuck looping in ntdll.dll!RtlpFreeHeap after calling kernel32.dll!FatalExit. This seems like a deterministic heap corruption.
Anyways, killing the NPFInstall.exe process unblocked the install and the Wireshark install seems to work fine.
Full callstack of NPFInstall.exe:
|- ntdll.dll!RtlUserThreadStart
| kernel32.dll!BaseThreadInitThunk
| NPFInstall.exe!__tmainCRTStartup
| NPFInstall.exe!doexit
| kernel32.dll!FatalExit
| ntdll.dll!RtlExitUserProcess
| ntdll.dll!LdrShutdownProcess
| ntdll.dll!LdrpCallInitRoutine
| sechost.dll!__DllMainCRTStartup
| sechost.dll!DllMain
| sechost.dll!SDllBaseInitialize
| sechost.dll!MitigationOptionNames::Release
| sechost.dll!std::basic_string<unsigned short,std::char_traits,std::allocator >::_Tidy
| ntdll.dll!RtlFreeHeap
| ntdll.dll!RtlpFreeHeapInternal
| ntdll.dll!RtlpFreeHeap
| |- ntdll.dll!RtlpFreeHeap
| |- ntdll.dll!RtlpAnalyzeHeapFailure
| |- ntdll.dll!RtlpLogHeapFailure
dmiller-nmap commentedon Apr 27, 2020
We recently switched to using HeapAlloc and HeapFree for NPFInstall, and we likely had a bug there. I've done some review and determined that the most likely place was in the
-wlan_write_regfunctionality of NPFInstall.exe, which we actually do not use for any purpose. I am stripping this code out, which should solve the heap corruption issue. In the meantime, avoiding the "Support raw 802.11 traffic (and monitor mode) for wireless adapters" installation option will avoid this code path.