问题标签 [windows-kernel]

我需要在不强制刷新元数据（文件大小，...）的情况下对附加到文件的字节范围进行 fsync。

错误信息：

错误 LNK2019：函数中引用了未解析的外部符号 _wcstok

但。wcslen作品

我正在使用一本书学习 Windows 的驱动程序开发。他们举了以下例子：

每当我尝试编译它时，我都会收到以下错误和警告：

我已经在 stackoveflow 中寻找解决方案，但在这种情况下它们似乎不起作用。我已经尝试禁用编译器警告，但仍然没有运气。

有人能解释一下吗？

我目前正在玩 Windows 内核驱动程序，以便更好地了解 Windows 内部结构。作为一个玩具项目，我编写了一个内核驱动程序，其作用是分配可以在进程之间共享的内存。

应用程序可以要求驱动程序创建任意大小的内存缓冲区。然后驱动程序使用 MmAllocatePagesForMdl 在 KernelSpace 中创建此缓冲区，然后在用户模式下使用MmMapLockedPagesSpecifyCache映射此缓冲区。结果指针被返回给应用程序，该应用程序可以像在任何普通缓冲区中一样直接写入它。然后另一个应用程序可以要求驱动程序访问该内存以读取它（甚至写入）；驱动程序只需在新进程的上下文中对现有缓冲区调用MmMapLockedPagesSpecifyCache 。到目前为止，一切都很好。

在这个小小的成功之后，我想在内核空间中创建一个更大的缓冲区，但我碰壁了。一个 MDL 最多只能管理“4Go - PAGE_SIZE”。

我的第一个想法是使用MmAllocatePagesForMdl创建多个 MDL，直到满足大小请求，使用Next指针链接 MDL，然后使用MmMapLockedPagesSpecifyCache返回指向用户空间的指针。但是MmMapLockedPagesSpecifyCache不适用于链式 MDL，它仅在用户空间中映射第一个 MDL。

到现在为止，我还没有找到从用户空间的内核空间返回超过 4Go 的连续虚拟内存的方法。内核空间中的分配不是问题，因为我使用内存分页，因此物理内存不必是连续的，但我找不到如何将它们映射到连续的虚拟内存中以在用户空间中使用。

那我是不是太贪心了，这是不可能的？还是我为了做到这一点而错过了什么？

有关信息，它是仅 64 位驱动程序和 64 位应用程序，因此此处没有 32 位限制。

在以下代码片段中，WinVerifyTrust 为系统上加载并运行的内核驱动程序文件 (.sys) 返回 CERT_E_UNTRUSTEDROOT：

一些有趣的点： - 驱动程序使用 SHA-256 使用有效（购买的）证书进行签名。- KB3033929 安装在系统上 (Win7/32) - 从文件属性查看证书时，整个证书链显示为有效

我打电话给 WinVerifyTrust 错了吗？

替代问题：是否有另一种方式知道（通过存在注册表项或类似的东西）基于 SHA-256 的代码签名验证在目标系统上可用？（我需要在安装过程中验证这一点......）

谢谢 ：）

我正在运行全新安装的 Windows。除了 VC 和 SDK 没有安装其他程序

• 包括目录

  C:\WinSDK10\Include\10.0.10586.0\shared;
  C:\WinSDK10\Include\10.0.10586.0\km;
  C:\WinSDK10\Include\10.0.10586.0\km\crt;
  C:\WinSDK10\Include\wdf\kmdf\1.11
  

• 目标操作系统版本

  视窗 8.1

• 目标平台

  桌面

• 运行 Wpp 跟踪

  不

• 启用最小重建

  不

哈克：如果我编辑wdm.h和删除驱动程序会成功构建#define _ETW_KM_

wdm.h

抱歉这篇文章太长了！！我很确定在遵循此MSDN 驱动程序示例链接
时我做错了，但我不知道是什么。

谢谢你的时间，

克里斯

我正在使用最新版本的 EasyHook 来挂钩一些内核功能。我确实在基于 Windows 8.1 64 位的虚拟机上成功设置了重要的调试，并且我测试了在用户模式下连接 NtQuerydirectoryFile 和 NtQuerySystemInformation 以及在内核模式下连接 NtQuerySystemInformation 没有任何问题。

我当前的问题是使用与用户模式挂钩相同的代码来挂钩 NtQuerydirectoryFile，但是当我调用原始函数时它会失败，给我一个访问冲突错误。我将以下代码用于内核模式挂钩：

提供最新的 WDK 以与支持 C++11 的 Visual Studio 15 一起使用。

但是，我还没有看到关于有多少功能可用的文档。

显然，我不会使用std::threadand std::mutex，但不太清楚的是魔术静力学。

这现在在用户模式下是线程安全的，但尚不清楚这种构造是否可以在内核中工作。

更令人担忧的是，内核中是否可以接受 C++11 之前的代码（假设析构函数是微不足道的）。

I writing a Windows Minifilter Driver which needs to read the entire file (only files with size up to a specific threshold) on IRP_MJ_CLEANUP. As FltReadFile may not be called from the preop callback I queued the job to a work queue and did it there. When I finish reading the file I call FltCompletePendedPreOperation and invoke the post-cleanup callback which also handles the post operation as deferred work. Here are snippets of my code:

This proves to work for a while but the system seems to hang (deadlock?) after a while. The problem seems to be with the call to FltReadFile since the hang does not occur when removing this call. Any ideas on why this might happen or how to debug it further?

我们正在尝试了解 Windows CPU 调度程序的工作原理，以优化我们的应用程序以实现最大可能的基础架构/实际工作比率。xperf 中有一些我们不理解的东西，希望社区能对真正发生的事情有所了解。当我们收到一些服务器“缓慢”或“无响应”的报告时，我们最初开始调查这些问题。

背景资料

我们有一个 Windows 2012 R2 服务器，它运行我们的中间件基础设施，具有以下规格。

我们发现 30% 的 CPU 浪费在内核上，所以我们开始深入挖掘。

上面的服务器运行“主机”~500 个进程（作为 Windows 服务），每个“主机”进程都有一个内部 while 循环，延迟约 250 毫秒（糟糕！），每个“主机”进程可能有 ~ 1..2 执行实际工作的“子”进程。

虽然在迭代之间具有 250 毫秒延迟的无限循环，但“主机”应用程序执行的实际有用工作可能仅每 10..15 秒出现一次。因此，不必要的循环浪费了很多周期。

我们知道“主机”应用程序的设计至少可以说是次优的，应用于我们的场景。应用程序正在更改为不需要循环的基于事件的模型，因此我们预计 CPU 利用率图中的“内核”时间会显着减少。

然而，当我们调查这个问题时，我们已经做了一些 xperf 分析，它提出了几个关于 Windows CPU 调度程序的一般问题，我们无法找到任何清晰/简洁的解释。

我们不明白的

下面是 xperf 会话之一的屏幕截图。

从“CPU Usage (Precise)”可以看出

• 有 15 毫秒的时间片，其中大部分没有得到充分利用。这些切片的利用率约为 35-40%。所以我假设这反过来意味着 CPU 大约有 35-40% 的时间被利用，但系统的性能（假设通过随意修改系统可以观察到）确实很慢。

• 有了这个，我们就有了这个“神秘”的 30% 内核时间成本，由任务管理器 CPU 利用率图判断。

• 一些 CPU 显然被用于整个 15 毫秒及更长的时间片。

问题

就多处理器系统上的 Windows CPU 调度而言：

• 是什么导致了 30% 的内核成本？上下文切换？还有什么？在编写应用程序以降低此成本时应考虑哪些因素？甚至 - 以最小的基础设施成本实现完美的利用率（在多处理器系统上，其中进程数高于内核数）
  • 这些 15 ms 切片是什么？
  • 为什么 CPU 利用率在这些切片中存在差距？