昨天我们有一个电源问题，导致我们的Windows Server 2003文件和打印服务器崩溃。 从那以后，我们一直有一些奇怪的印刷问题。 虽然这一切都应该通过从备份恢复来纠正，但我真的正在寻找可能的解释。
有两个截然不同的问题，我认为它们有共同的根源。
当事件2发生时，客户端或服务器上的日志中没有任何内容表明存在问题。 客户端是XP 32位和Win 7 64位的混合，所以他们甚至不使用相同的驱动程序。 重新启动机器，包括服务器，不起作用。
在一个客户端上，我尝试删除现有的打印机并重新创build它。 在这一点上，我收到了“访问被拒绝”，虽然后台打印程序文件，文件夹和共享的权限没有改变，仍然是正确的。 所有打开最大访问权限的testing都不会改变行为。
对于哪些用户帐户（或组）或哪些客户端计算机受到影响似乎没有模式。 临时解决方法是将打印机创build为本地，而不是通过服务器。 幸运的是，我们有相当less的用户。
任何人都在考虑深层次的问题是什么？
多一点古怪
渐渐地，那些已经能够打印的用户发现他们已经不能再这样做了。 作为一个testing，我重新启动了一台仍然可以打印的客户端电脑。 这没有效果，但大约一个小时后，机器也不能再打印。 每个人现在都将每台打印机设置为本地，从而（暂时）从等式中删除服务器。
我应该补充一点，我仍然可以从服务器本身打印每台打印机，并且从完成断开客户端后，假脱机程序没有崩溃。
更新
删除一个打印机型号的驱动程序对所有其他打印机都具有正常的function。 重新安装这些驱动程序拧紧所有的打印机。 这应该不可能，但这就是发生了什么事情。 到目前为止，我已经从备份中恢复，试图解决问题的根源，但现在放弃了。
这是一个奇怪的。 如果你可以离开，只是从备份恢复服务器可能是你最好的select。
假脱机程序服务是否在服务器计算机上干净地closures，还是崩溃？ 如果服务意外终止，则应该从服务控制pipe理器获取消息（以及指示在正在closures时收到“停止”控制消息的消息）。
我的经验是，错误的驱动程序或打印处理器几乎总是在Windows Server计算机上意外终止后台打印程序服务的原因。 查看一个由失败产生的内存转储的堆栈跟踪可能会让你知道哪个驱动正在做这件事。 否则，如果你想追查有问题的驱动程序，你就会被排除在外。 也许你在其中一个驱动文件的数据stream中发生了一些损坏。
你所看到的并没有发生在我的经验。 我们现在有几个客户正在将大量的64位Windows 7投入生产，并且我们发现在客户端计算机上有时会出现奇怪的行为（特别是对于Microsoft Excel 2007–testing页面将会打印很好，但是当任何打印相关的function，如“页面设置”或“打印预览”被选中时，Excel将会挂起），但是没有任何东西像你所描述的那样。
如果你有方便的恢复从备份框我想我会做到这一点。
由于服务器遭遇电源事件，是否发生了基本的“堵塞”？