Closed l1TTss closed 4 years ago
Thanks for this report. I'm analyzing the crash right now; it looks like there's some corruption in the capture data structures. What were you doing just prior to the crash? Did you have more than one capture handle open, for example more than one instance of Wireshark running?
Using the Nessus (version:8.10.1)for vulnerability scanning.
------------------ Original ------------------ From: Daniel Miller <notifications@github.com> Date: Thu,Jul 16,2020 0:37 PM To: nmap/npcap <npcap@noreply.github.com> Cc: l1TTss <158844686@qq.com>, Author <author@noreply.github.com> Subject: Re: [nmap/npcap] Using Npcap 0.9995 results in BSOD. (#206)
Thanks for this report. I'm analyzing the crash right now; it looks like there's some corruption in the capture data structures. What were you doing just prior to the crash? Did you have more than one capture handle open, for example more than one instance of Wireshark running?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
I think I figured it out, but I'm not at my debugger to verify. The pNBCopies object is refcounted twice, but may be freed/returned three times. Need to check the proper order of object pool returns in NPF_FreeCapData. Hopefully this will make sense to me in the morning.
I think I figured it out, but I'm not at my debugger to verify. The pNBCopies object is refcounted twice, but may be freed/returned three times. Need to check the proper order of object pool returns in NPF_FreeCapData. Hopefully this will make sense to me in the morning. … Thank you very much for your effort.But newer versions often introduce new problems easily, and let's make it better later.
Upon further investigation, it does not seem that refcounting is the problem. The minidump does not have one of the important pages of memory for me to track everything that is going on, but here is the code in question, from NPF_Read()
:
PNET_BUFFER pNetBuf = pCapData->pNBCopy->pNetBuffer;
// NetBuffers that we create for copy don't use offsets and
// begin right at the beginning of FirstMdl
PMDL pMdl = NET_BUFFER_FIRST_MDL(pNetBuf);
The crash is a read access to 0x0000000000000020, which corresponds to the offset of MdlChain
within the a NET_BUFFER
, so pNetBuf == NULL
, and I'm trying to determine how that could happen.
I have been testing 0.9995 for the last week and have been having hangs in my test lab environment. This environment is PROXMOX virtual space and I am not seeing BSOD's but I am seeing hangs on most of my windows boxes within 8 hours of a reboot/install of NPCAP.
In testing I tried 0.9994 and 0.9995 with the same results. I went back to the version we are shipping ( OEM ) 0.9984 which I am at 24 hours w/o a crash/hang.
I have no memory dump info. I can try to get it but we are unable to upgrade to the 0.9995 version to fix the issue with RCS on 10GB adapters reported previously until there is stability.
THanks! I can try to pull other data if you need.
The hang is a memory leak (#213) that may or may not be related to this crash. The code responsible for these structures has been extensively rewritten to be more efficient and avoid similar crashes. We expect to be able to make a new release this week.
We believe this has been fixed in Npcap version 0.9996
Using Npcap 0.9995 results in a computer blue screen.(BSOD) 071620-10562-01.zip