VS debugging encounters the "Application interruption mode" problem again, with a solution attached, vs debugging

VS debugging encounters the "Application interruption mode" problem again, with a solution attached, vs debugging

Some colleagues reported that debugging was abnormal during the recent reconstruction of a project. It happened a long time ago. Although I searched for a solution, I thought it was necessary to record it.

To debug an application with a CS structure, you can see the following figure:

 

The final solution of our group is to set the compiled target platform to X64 instead of AnyCPU or X86.

I have developed an OCR (Optical Character Recognition) Client tool in the previous factory. I remember it very clearly because it took a long time to find a solution.

The problem encountered during the development of this tool is that the LoadLibrary cannot be implemented, because the self-identified library I called is released by a third party and must be called by this third-party library (with DllImport ), I thought it was okay to directly reference the COM component.

However, during actual development, it is found that the code returned by GetLastError is 193. The MSDN explanation is: % 1 is not a valid Win32 application.

The debugging is the same as the "Application interruption mode" mentioned above.

After debugging the experiment repeatedly, the final solution is to set the compiling target platform to X86 instead of AnyCPU or X64.

I want to know the cause of debugging interruption. I think that our group recently cited a library compiled by the architecture department. The target platform is X64, And the OCR Automatic Identification library, boldly infer that the target platform may be X86.

The following is the final conclusion of this article:

If your application References Libraries or third-party libraries, pay attention to the target platform generated by dll. Otherwise, the "Application interruption mode" error may be reported during debugging.