MultiByteToWideChar rarely causes an access violation and the software terminates abnormally.

[kikuchi]

MultiByteToWideChar rarely causes an access violation and the software terminates abnormally.
The frequency is about once every several dozen times. However, if the software does not crash after it is started, it will not crash while the software is running.
Start the software → call a function (if it does not fall down, it will not fall down for a long time, and if it falls down, it will fall down in one shot).

Operating environment
OS: Windows 10 Pro 21H1
C# EXE (.net framework 4.5.2): FunctionA Call⇒ FunctionB
C++ DLL( Intel Compiler 2016 update4): FunctionB (calls MultiByteToWideChar in a function)
-----------------
[Code on C# side]
public class TestClass{
internal static class NativeMethods
{
[DllImport(@"DLL\Test.dll", CallingConvention = CallingConvention.Cdecl)]
internal static extern int FunctionB(byte[] pszImageFile);
}

void FunctionA( string filePath ){
System.Text.Encoding enc = System.Text.Encoding.UTF8;
byte[] pszImageFile = enc.GetBytes(filePath);
NativeMethods.FunctionB(pszImageFile);
}
}
-----------------
[Code on C++ side ]
void FunctionB( const char *pszImageFile ){

TCHAR szImageFileWcs[MAX_PATH];
MultiByteToWideChar(CP_UTF8, 0, pszImageFile, MAX_PATH, szImageFileWcs, sizeof(szImageFileWcs) / sizeof(TCHAR));
}
-----------------

Supplementation
The argument filePath of FunctionA is a character string including the Japanese path, but not more than 60 characters including Japanese.
The DLL created by the C++ IntelComplier Release build is used by calling it in C#.
If you use C++ IntelComplier Debug build, it doesn't fall down.
When VS compiler is used, both Relase and Debug versions do not fail.
There is a pattern that the code is modified in a place that has nothing to do with MultiByteToWideChar, and it does not fail.
　- If the array allocated by TCHAR is doubled [it will not fall down] (TCHAR szImageFileWcs[ 520 ] )
　- If you put a definition like L "TEST LOG"; in the scope of FunctionB for debug logging, it will not fail.
　- Define #define LOG_MSG L "TEST LOG" outside the scope of FunctionB for debug logging and use it.

Translated with www.DeepL.com/Translator (free version)

[NoorjahanSk_Intel]

Hi,

Thanks for reaching out to us.

>>Intel Compiler 2016 update4 

Could you please try the latest Intel C++ compiler(2021.5)? 

You can get the latest compiler by downloading HPC Toolkit.

Please refer to the below link to download the HPC Toolkit:

https://www.intel.com/content/www/us/en/developer/tools/oneapi/hpc-toolkit-download.html

If the issue still persists with the latest compiler, please do let us know with the following details:

>>Start the software → call a function (if it does not fall down, it will not fall down for a long time, and if it falls down, it will fall down in one shot).

•  Could you please let us know, what is the software you are referring to in the above statement?
•  Could you please let us know what do you mean by fall down and how did you observe it?

Also please provide the complete reproducer(steps if any) along with the input that you have provided to the code and expected output that you got.

Thanks & Regards,

Noorjahan

[kikuchi]

Thank you for your answer.

>> Could you please try the latest Intel C++ compiler(2021.5)? 
We will try to verify this. However, there is a workaround with the current compiler.
The only way to do that is to increase the array size in the local scope or define a string.
>> If the array allocated by TCHAR is doubled [it will not fall down] (TCHAR szImageFileWcs[ 520 ])
>> If you put a definition like L "TEST LOG"; in the scope of FunctionB for debug logging, it will not fail.

The basis for determining an access violation is the EventViwer log after the software has terminated abnormally.

------ Some excerpts -----
Framework version: v4.0.30319
description: process aborted due to unhandled exception
Exception information: System.AccessViolationException
HMIFrame.ParamAutoExecution+NativeMethods.GetImage(System.String, Byte[], Int32, Byte[], Int32 ByRef, Int32 ByRef, Int32 ByRef)
---------------------

In the actual software, the problem occurs in the function GetImage.
FunctionB has been described without arguments and other information for the sake of explanation.

Currently, the problem is caused by either the Debug build or the compiler (platform toolset) being changed from Intel compiler to
We believe that the problem may be caused by program optimization at compile time, since the problem does not occur when changing to Visual Studio 2012.

Please wait a moment as we are unable to provide a reproducible environment immediately.

[NoorjahanSk_Intel]

Hi,

>>Please wait a moment as we are unable to provide a reproducible environment immediately.

Could you please provide us with an update about your issue?

Could you please share the reproducer to try it from our end?

Thanks & Regards,

Noorjahan.

[NoorjahanSk_Intel]

Hi,

We have not heard back from you, so we will close this inquiry now. If you need further assistance, please post a new question.

Thanks & Regards,

Noorjahan.