HCK对我们的NDIS LWF有0个测试？ HLK不包括NDIS测试6.5 LWF徽标测试？
随着交叉签名现在不推荐使用，我们正在尝试通过HCK和HLK测试，以便我们的NDIS LWF安装在7台以上的机器上，我们的LWF使用NDIS 6.0。
我的问题是：
当我们在HCK中选择驱动程序时，有0个测试，即使是我们的LWF也明确安装了，这是否是正常的？
当我们运行HLK 1607时，只有两个基本测试是TDI和Hyper-V准备测试，但是没有NDIS 6.5 LWF徽标测试。我们只需要通过这两个测试吗？
在创建软件包之前，我们是否应该添加包含驱动程序 + IT INF的文件夹？或我们的驱动程序自动被捆绑在生成的HLKX文件中？
请注意，我们不使用任何播放列表，尽管我仍然不确定这些播放列表有什么关系，以及我们是否需要使用播放列表或仅使用默认列表？
As cross signing is now deprecated, we are trying to pass the HCK and HLK test in order for our NDIS LWF to install on 7+ machines, and our LWF uses NDIS 6.0.
My questions are:
When we select our driver in HCK, there are 0 tests available, even tho our LWF is clearly installed, Is this normal?
When we run HLK 1607, there are only the two basic tests, which are the TDI and Hyper-V readiness test, but there is no NDIS 6.5 LWF Logo test. Do we only need to pass these two tests?
Should we add the folder that contains our driver + its inf in the package tab, before creating the package? Or our driver automatically gets bundled in the hlkx file that gets generated?
Note that we are not using any playlist, although i am still not sure what's the deal with these playlists and whether or not we need to use a playlist or just use the default one?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
关于前几个问题，是的，这听起来很正常。老实说，我们（Microsoft的NDIS团队）不知道如何测试任意的NDIS LWF。 LWF可以做很多不同的事情，以至于我们可以尝试进行的任何通用测试可能会对某些过滤器驱动器造成假阴性。例如，一项验证各种网络流量通过LWF的测试可能会在防火墙驱动程序上失败，而防火墙驱动程序的工作是放弃可疑流量。在许多情况下，LWF在某些第三方USERMODE应用程序为其设置了一些配置之前根本没有做任何事情。例如，QoS滤波器可能在NO-OP模式下运行，直到某些USERMODE应用程序按下QoS策略。我们构建的任何通用测试都将练习NO-OP模式，我们完全会错过驾驶员的有趣部分。
因此，就目前而言，您在很大程度上是在荣誉系统上，您已经正确实施了NDIS合同，并在测试其功能方面进行了尽职调查。
当然，我们保留将来添加更多测试的权利，如果很明显这将使我们的共同客户受益。
请注意，驱动程序验证器（DV）包括一个“ NDIS/WIFI”标志：如果启用该模式，NDIS将自动验证其许多编程合同。因此，如果您正在寻找正确完成工作的保证，请确保使用启用DV + NDIS/WIFI练习LWF的各种情况。通常，DV在每个OS版本中都会变得更好，因此，即使您的LWF针对较旧的操作系统，对最新OS版本的测试也会捕获最多的错误。
至于您的第三个问题：我不知道。 （具有讽刺意味的是，我本人无法访问驾驶员提交管道，因此我从来没有从您的角度尝试过任何事情。）
Regarding the first couple questions, yes that sounds normal. We (the NDIS team at Microsoft) honestly don't know how to test an arbitrary NDIS LWF. LWFs can just do so many different things, that any generic test we could try to make would probably cause a false negative for some filter driver. For example, a test that verifies various types of network traffic pass through the LWF would likely fail on a firewall driver, whose very job is to drop suspicious traffic. And in many cases, LWFs do nothing at all until some 3rd party usermode application sets up some configuration for them. For example, a QoS filter probably operates in a no-op mode until some usermode application pushes down QoS policies; any generic test we build would just be exercising the no-op mode, and we'd completely miss the interesting part of the driver.
So for now, you're largely on the honor system that you've implemented NDIS contract correctly and done your due diligence in testing its functionality.
We reserve the right to add more tests in the future, of course, if it becomes clear that this would benefit our mutual customers.
Note that Driver Verifier (DV) includes an "NDIS/WIFI" flag: if you enable that mode, NDIS will automatically verify many of its programming contracts. So if you're looking for some assurance that you've done things correctly, make sure you exercise your LWF's various scenarios with DV + NDIS/WIFI enabled. In general, DV gets a bit better with each OS release, so testing on the latest OS version will catch the most bugs, even if your LWF is targeted towards an older OS.
As to your third question: I don't know. (Ironically, I don't have access to the driver submission pipeline myself, so I have never actually tried things from your point of view.)