As the title says I have a .NET application that is the GUI which uses multiple threads to perform separate file I/O and notice that the threads occasionally block when the application is protected by Themida.

One thread is devoted to reading from serial COM port and another thread is devoted to copying files. What I experience is occasionally when the file copy thread encounters a network delay, it will block the other thread that is reading from the serial port. In addition to slow network (which can be transient), I can cause the problem to happen more frequently by making a PathFileExists call to a bad path e.g.

PathFileExists("\\\\BadPath\\file.txt");

The COM port reading function will block during the call to ReadFile. This only happens when the application is protected by Themida. I have tried under WinXP, Win7, and Server 2012.

In a streamlined test project, if I replace the .NET application with a MFC unmanaged application and still utilize the same threads I see no issue even when protected with Themida.

I have contacted Oreans support and here is their response:

The way that a .NET application is protected is very different from a native application.

To protect a .NET application, we need to hook most of the file access APIs in order to >"cheat" the .NET Framework that the application is protected. I guess that those special >hooks (on CreateFile, ReadFile...) are delaying a bit the execution in your application >and the problem appears. We did a test making those hooks as light as possible (with >minimum code on them) but the problem still appeared in your application.

The rest of software protectors that we tried (like Enigma, Molebox...) also use a similar >hooking approach as it's the only way to make the .NET packed file to work. If those hooks >are not present, the .NET Framework will abort execution as it will see that the original >file was tampered (due to all Microsoft checks on .NET files)

Those hooks are not present in a native application, that's why it should be working fine >on your native application.

Oreans support tried other software protectors such as Enigma Protector, Engima VirtualBox, and Molebox and all exhibit the exact same problem.

What I have found as a work around is to separate out the file copy logic (where the file exists call is being made) to be performed in a completely separate process.

I have experimented with converting the thread functions from unmanaged C++ to VB.NET equivalents (PathFileExists -> System.IO.File.Exists and CreateFile/ReadFile -> System.IO.Ports.SerialPort.Open/Read) and still see the same serial port read blocked when the file check or copy call is delayed. I have also tried setting the ReadFile to work asynchronously but that had no effect.

I believe I am dealing with some low-level windows layer that no matter the language it exhibits a block on a shared resource -- and only when the application is executing under a single .NET process protected by Themida which evidently installs some hooks to allow .NET execution.

At this time converting the entire application away from .NET is not an option. Nor is separating out the file copy logic to a separate task. I am wondering if anyone else has more knowledge of how a file operation can block another thread reading from a system port.

I have included here example applications that show the problem:

https://db.tt/cNMYfEIg - VB.NET

https://db.tt/Y2lnTqw7 - MFC

They are Visual Studio 2010 solutions. When running the themida protected exe, you can see when the FileThread counter pauses (executing the File.Exists call) while the ReadThread counter also pauses. When running non-protected visual studio output exe, the ReadThread counter does not pause which is how we expect it to function.

Thanks!