正如标题所说，我有一个.NET应用程序是GUI，它使用多个线程来执行单独的文件I / O，并注意到当应用程序受Themida保护时，线程偶尔会阻塞。
一个线程专门用于从串行COM端口读取，另一个线程专门用于复制文件。我经历的有时是文件复制线程遇到网络延迟时，它会阻塞从串口读取的另一个线程。除了慢速网络（可能是短暂的）之外，我可以通过对不良路径进行PathFileExists调用来更频繁地解决问题，例如。
PathFileExists("\\\\BadPath\\file.txt");
COM端口读取功能将在调用ReadFile期间阻止。这仅在应用程序受Themida保护时才会发生。我在WinXP，Win7和Server 2012下尝试过。
在一个简化的测试项目中，如果我用一个MFC非托管应用程序替换.NET应用程序并仍然使用相同的线程，即使用Themida保护，我也没有看到任何问题。
我已联系过Oreans的支持，以下是他们的回复：
.NET应用程序受保护的方式与本机应用程序非常不同。
为了保护.NET应用程序，我们需要挂钩大多数文件访问API，以便＆gt;＆＃34;欺骗＆＃34;应用程序受保护的.NET Framework。我想那些特殊的＆gt;钩子（在CreateFile，ReadFile ......上）会延迟你的应用程序中的执行＆gt;并出现问题。我们做了一个测试，使这些钩子尽可能轻（在它们上面有＆gt;最小代码），但问题仍然出现在你的应用程序中。
我们尝试的其他软件保护程序（如Enigma，Molebox ......）也使用类似的＆gt;挂钩方法，因为它是使.NET打包文件工作的唯一方法。如果这些挂钩＆gt;不存在，.NET Framework将中止执行，因为它将看到原始＆gt;文件被篡改（由于所有Microsoft对.NET文件的检查）
这些钩子不存在于本机应用程序中，这就是为什么它应该在您的本机应用程序上正常工作。
Oreans支持尝试其他软件保护程序，如Enigma Protector，Engima VirtualBox和Molebox，并且都表现出完全相同的问题。
我发现作为一种解决方法是将文件复制逻辑（正在调用文件的位置）分开，以便在一个完全独立的过程中执行。
我已尝试将线程函数从非托管C ++转换为VB.NET等价物（PathFileExists - ＆gt; System.IO.File.Exists和CreateFile / ReadFile - ＆gt; System.IO.Ports.SerialPort.Open/Read）并且在文件检查或复制呼叫延迟时仍然看到相同的串行端口读取被阻止。我也试过将ReadFile设置为异步工作，但没有效果。
我相信我正在处理一些低级别的windows层，无论它在共享资源上显示块的语言 - 并且只有当应用程序在受Themida保护的单个.NET进程下执行时才显然安装了一些钩子允许.NET执行。
此时将整个应用程序转换为.NET不是一种选择。也没有将文件复制逻辑分离为单独的任务。我想知道是否有其他人更了解文件操作如何阻止从系统端口读取另一个线程。
我在这里包含了显示问题的示例应用程序：
https://db.tt/cNMYfEIg - VB.NET
https://db.tt/Y2lnTqw7 - MFC
它们是Visual Studio 2010解决方案。运行themida protected exe时，您可以看到FileThread计数器何时暂停（执行File.Exists调用），同时ReadThread计数器也会暂停。当运行不受保护的visual studio输出exe时，ReadThread计数器不会暂停，这是我们期望它运行的方式。