HI Graham, Good work. There should be someone reporting this. I just doubt their QA guy of driver team doesn't do his work for such an obvious issue.
Remote debugging in VS is currently enough for me. Also I don't think it's possible to use the automatic deployment for Npcap as it's installed using a helper program (NPFInstall.exe). And I don't use test (although I should create one about performance test). I will check it when I got a BSoD issue for Npcap driver. Thanks! Cheers, Yang On Fri, Apr 15, 2016 at 7:11 PM, Graham Bloice <[email protected]> wrote: > > > On 14 April 2016 at 11:01, Graham Bloice <[email protected]> > wrote: > >> >> >> On 14 April 2016 at 01:07, Yang Luo <[email protected]> wrote: >> >>> Hi Graham, >>> >>> On Thu, Apr 14, 2016 at 12:50 AM, Graham Bloice < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On 13 April 2016 at 17:26, Yang Luo <[email protected]> wrote: >>>> >>>>> Hi Graham, >>>>> >>>>> On Wed, Apr 13, 2016 at 6:11 PM, Graham Bloice < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 13 April 2016 at 06:07, Yang Luo <[email protected]> wrote: >>>>>> >>>>>>> Hi Guy, >>>>>>> >>>>>>> As you know, Npcap/WinPcap is currently based on libpcap 1.0 branch >>>>>>> 1_0_rel0b (20091008), which is a very old version. >>>>>>> Adding features to so old wpcap.dll code will put me even farther >>>>>>> away from the libpcap trunk. >>>>>>> So I wanted to use the latest libpcap code in Npcap before adding >>>>>>> code. Actually I posted a thread on tcpdump list about how to build >>>>>>> libpcap >>>>>>> on Windows before. But no solutions. >>>>>>> >>>>>>> Do you know how to build libpcap into wpcap.dll? >>>>>>> I guess Loris developed the 1st generation WinPcap and ported >>>>>>> libpcap into wpcap.dll. How did he achieve this? >>>>>>> >>>>>>>> >>>>>>>> >>>>>> This is one of the priority items on my TODO list, >>>>>> >>>>> >>>>> Good to hear it:) >>>>> >>>>> >>>>> >>>>>> however first I want to finish off getting all the Visual Studio Code >>>>>> Analysis issues first which has stalled due to lack of time, >>>>>> >>>>> >>>>> I also gave a shot of using "Analyze" -> "Run Code Analysis" in VS2015 >>>>> against Npcap driver project. It supplied me so many trivial alarms which >>>>> are definitely not going to happen, like assuming the CPU count is 0. >>>>> >>>> >>>> I agree that some of the flagged issues are somewhat extreme, however >>>> that particular area of code does have some issues with the locks obtained >>>> and the IRQL. I have a change for that pending but need to test some more. >>>> >>>> I think for a driver we need to get it compiling as clean as possible, >>>> no warnings at all. >>>> >>>> >>>>> >>>>>> and the fact that VS2015 Update 1 has totally broken driver remote >>>>>> deploy and test. I need to check if Update 2 has fixed that. >>>>>> >>>>> >>>>> I'm using VS2015 Update 2 now. I have confirmed that the remote >>>>> debugging is still not fixed. I use the "Network" connection way and it >>>>> gave me: >>>>> >>>>> >>>>> ---------------------------------------------------------------------------------- >>>>> Installing necessary components... >>>>> Failed operation: An error occurred while connecting from the remote >>>>> machine. >>>>> Error: 10060 (TimedOut) >>>>> Error message: A connection attempt failed because the connected party >>>>> did not properly respond after a period of time, or established connection >>>>> failed because connected host has failed to respond >>>>> 192.168.47.139:50005 >>>>> >>>>> ---------------------------------------------------------------------------------- >>>>> >>>>> So I guess the only workaround for now is rolling back to VS2013. >>>>> >>>>> >>>> This seems to have changed though, before even attempting to configure >>>> it caused an error. I shall try to have a look at that tonight. >>>> >>>> Personally I don't mind going back to VS2013 because at least the >>>> debugging worked there, but what WDK do we use then, continue with Win 10 >>>> (if that's possible), or use 8.1? >>>> >>> >>> Only the following two pairs work out. >>> >>> 1) VS2013 + WDK8.1 >>> 2) VS2015 + WDK10 >>> >>> I have already adapted to the situation without remote IDE debugging. I >>> primarily troubleshoot minor issues by looking at the print log. And for >>> BSoD, I just analyze the dump file for causes. These two ways are barely >>> adequate for me temporarily. >>> >>> >> I did manage to get VS2015 remote kernel debugging running last night, it >> seems it's just the automated deploy of the driver that's broken. I raised >> an issue on Microsoft Connect for that: >> http://connect.microsoft.com/VisualStudio/feedback/details/2586448/unable-to-remote-deploy-a-driver-for-testing >> >> I think I'll be able to manually install the driver, not sure how I can >> run the tests yet though. >> >> > The Visual Studio debugging team have confirmed the issue, but marked it > as "External" as it's a Visual Studio plugin (probably installed by the > WDK) that's at fault. > > They have passed it on to the appropriate team but we don't have external > visibility of what they're doing about it now. The debugging team did say > to follow up with them if I don't hear anything back. > > -- > Graham Bloice > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
