使用Windows驱动程序开发工具包示例包（v 8.1），我找到了一个示例打印处理器实现，我尝试将其用作我自己的自定义打印处理器的起点（＆＃34; GenPrint打印处理器示例＆＃34 ）。我设法在Visual Studio 2017社区中成功构建它（将PlatformToolset更改为＆＃34; v141＆＃34;），我显然能够成功安装它（通过创建注册表项，＆＃34; HKLM： \ SYSTEM \ CurrentControlSet \ Control \ Print \ Environments \ Windows x64 \ Print Processors \ genprint＆＃34; with item property＆＃34; Driver＆＃34;和value＆＃34; genprint.dll＆＃34;，并复制新建的dll到％WinDir％/ System32 / spool / prtprocs / x64 /）。然后我可以设置一个测试打印机并选择我的＆＃34; genprint＆＃34; <使用打印机属性打印处理器>高级＆gt;打印处理器...，我甚至可以从Visual Studio中的调试器附加到假脱机程序进程spoolsv，并在EnumPrintProcessorDatatypesW（...）中设置断点，当我重新打开打印处理器对话框时看到它被点击测试打印机。到目前为止，太棒了！
当我在其他地方设置断点并将实际作业排队到打印机队列时，问题就出现了。在OpenPrintProcessor（...）的开头说。或PrintDocumentOnPrintProcessor（...），或者，你命名它。没什么，nada，zilch。似乎这些函数只是从未被调用，至少不是我的DLL导出的实现。我甚至在DLL导出的每个函数的开头都插入事件日志ala事件跟踪（ETW），但是生成的唯一日志是EnumPrintProcessorDatatypesW（...）的日志。
地球上可能会发生什么？是否有可能由于一些奇怪的原因，假脱机程序使用不同的打印处理器而不是我的，即使我明确地将我的打印队列与相关的打印队列相关联？如果是这样，为什么？
[更新：看起来我看到的行为已经归结为＆＃34;打印驱动程序隔离＆＃34 ;;当我将与队列关联的驱动程序的隔离模式更改为＆＃34;无＆＃34;时，我可以附加到spoolsv进程。否则，我的打印处理器在一个单独的进程中运行，通过DCOM与spoolsv进行通信，如下所述：https://blogs.technet.microsoft.com/askperf/2009/10/08/windows-7-windows-server-2008-r2-print-driver-isolation/ - 我猜测系统范围的默认值已被更改为使用打印驱动程序隔离，因为后Windows 7，除非您明确将驱动程序配置为＆＃34;无＆＃34; （或者它以这种方式配置）]