Windows 为什么单个PDF的PDF文本提取会挂起,但可以通过RDP工作

Windows 为什么单个PDF的PDF文本提取会挂起,但可以通过RDP工作,windows,pdf,fonts,tesseract,remote-desktop,Windows,Pdf,Fonts,Tesseract,Remote Desktop,我有一个从PDF中提取文本的程序。它在Windows Server 2008上作为计划任务运行 我使用的库是ByteScout的PDF提取器SDK,它是基于Tesseract的 自去年11月上线以来,该项目已成功地从许多不同来源的50000多个PDF文件中提取文本 它最近挂起了一个PDF文件,随后又挂起了第二个PDF文件,它们来自同一个源,采用相同的视觉格式 我能够用一个简单的12行程序重现这个问题。我将此程序发送给供应商,但在他们的环境中运行该程序可以正常工作(不会挂起) 所以我做了一些实验,

我有一个从PDF中提取文本的程序。它在Windows Server 2008上作为计划任务运行

我使用的库是ByteScout的PDF提取器SDK,它是基于Tesseract的

自去年11月上线以来,该项目已成功地从许多不同来源的50000多个PDF文件中提取文本

它最近挂起了一个PDF文件,随后又挂起了第二个PDF文件,它们来自同一个源,采用相同的视觉格式

我能够用一个简单的12行程序重现这个问题。我将此程序发送给供应商,但在他们的环境中运行该程序可以正常工作(不会挂起)

所以我做了一些实验,这就是它变得奇怪的地方

如果我使用RDP连接到我的电脑(Windows 7),该程序可以在电脑上运行,但如果我直接登录,则无法运行。此行为在我们环境中的其他Windows 7 PC上重复

如果我是RDPed,它在Server2008上工作,但不是作为计划任务

它在Windows 10上工作,无论我是RDPed还是直接登录

如果我在Process Monitor中看到程序卡住时,我可以看到它正在打开并反复读取C:\Windows\Fonts\times.ttf

如果它只是使用RDP工作,我想知道原因是否与未能使用图形加速或诸如此类的东西有关,但是考虑到它不能作为一个计划任务工作,也不会出现任何问题,我认为这是一条死胡同


有人对下一步该去哪里有什么建议吗?

所以Bytes不可能解决这个问题。引用尤金的话来解释原因

问题出在System.Drawing和GDI+中。有时,它会在PDF中正常的文本绘制操作上崩溃,但会导致System.drawing中出现一些内部异常。此外,它的行为因显示设备的功能而异。这就是为什么它在RDP会话中工作,并在桌面上崩溃。 我们正在尝试各种解决这些崩溃的方法,试图退回到其他文本绘制方式。绞刑与这些退路有关