Access Violation After GET Webpage - page 2

[Dominik Egert]

Jeronymite #:

Thanks, Dominik.

As previously mentioned, the code is part of a large proprietary project, and the specific area of code is quite sensitive. I would, however, be willing to work with you, perhaps online together to demonstrate and to try to diagnose any issue or create code that can reproduce the problem. Would that be possible?

MT5 Version: 5.00 build 4153, 22 Jan 2024.

Windows 10 Pro 22H2, build 19045.3930 with Windows Feature Experience Pack 1000.19053.1000.0. [32 GB memory, Intel Core i7-3920XM CPU @ 2.90GHz, 3.10 GHz]

Thanks.

We can try, I'll PM you.

Edit: Please accept friend request.

[Soewono Effendi]

You're using DLL returning string/char array that might overflow.

Read the article I shared above.

Good luck

[Dominik Egert]

The issue has been resolved in a private session.

Actually, it is the function signature definitions of the imported functions as they are defined in MT5 supplied files. A snippet of the finding is here:

winreg.mqh:

int     RegOpenKeyExW(HANDLE key,const string sub_key,uint options,uint desired,HANDLE &result);

which is defined by Microsoft official documentation as:

LSTATUS RegOpenKeyExW(
  [in]           HKEY    hKey,
  [in, optional] LPCWSTR lpSubKey,
  [in]           DWORD   ulOptions,
  [in]           REGSAM  samDesired,
  [out]          PHKEY   phkResult
);

https://learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regopenkeyexw

Where HKEY is defined as:

typedef void *PVOID;
typedef PVOID HANDLE;
typedef HANDLE HKEY;

https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types

And LPCWSTR is defined as:

typedef wchar_t WCHAR;
typedef CONST WCHAR *LPCWSTR;

https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types

And DWORD is defined as:

typedef unsigned long DWORD;

https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types

As annotation here, it is not exactly clear to me if this should be a 64 bit or 32 bit variable. - Consulting C++ documentation "unsigned long" should be at least 32 bit, depending on the target type. - Since MT5 is 64 bit, and the target architecture is 64 bit, this should result in a 64 bit type.

https://en.cppreference.com/w/cpp/language/types

And REGSAM is defined as:

typedef DWORD ACCESS_MASK;
typedef ACCESS_MASK REGSAM;

https://learn.microsoft.com/en-us/previous-versions/bb401738(v=msdn.10)

And PHKEY is defined as:

typedef HKEY *PHKEY;

https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types

The return value type is a bit difficult, as can be seen in this discussion: https://github.com/microsoft/win32metadata/issues/760

So, according to the resolution on that thread:

typedef long LONG;
typedef LONG LSTATUS;

Same definition issue with this as with DWORD. - See above. - So, in conclusion it should b e 64 bit.

Therefore the actually valid signature seems to be:

long     RegOpenKeyExW(ulong key, const short& sub_key[], ulong options, ulong desired, ulong& result);

After changing the signature to represent Microsoft's documentation, the reported issues were gone.

EDIT:

typedef in MQL5 is broken, and only supports function pointers. - Contrary to documentation.

[Soewono Effendi]

Thanks for the update. 

I remember seeing this some where:

To access DLL in MT4 (32bit), when you use:
- int / uint
- char / uchar

for MT5 (64bit), you use instead:
- long / ulong
- short / ushort

[Dominik Egert]

Soewono Effendi #:
Thanks for the update. 

I remember seeing this some where:

To access DLL in MT4 (32bit), when you use:
- int / uint
- char / uchar

for MT5 (64bit), you use instead:
- long / ulong
- short / ushort

I don't think this applies across the board. It depends, and it is worth looking at the documentation by MS, just to be sure.

But your hint with a buffer overflow was obviously correct. - Actually it was a stack corruption, that's been taking place.

[Soewono Effendi]

Glad that everything resolved.

Good job.

[Jeronymite]

Dominik Egert #:

I don't think this applies across the board. It depends, and it is worth looking at the documentation by MS, just to be sure.

But your hint with a buffer overflow was obviously correct. - Actually it was a stack corruption, that's been taking place.

Many thanks to Dominik Egert for very kind and generous assistance to investigate, diagnose and rectify the problem. Many thanks to him also for his comprehensive summary of the process and outcomes!

Obviously, there are implications here for the accuracy of the WinAPI Include files provided by MetaQuotes. One might hope they would be reviewed, validated against Microsoft signatures, and updated where need be to completely align with those Microsoft signatures.

Meanwhile, it is important to be aware of their deficiencies and the possible side effects when Optimization is enabled.

Thanks, again, Dominik Egert !

[Ilyas]

Dominik Egert #:

The issue has been resolved in a private session.

Actually, it is the function signature definitions of the imported functions as they are defined in MT5 supplied files. A snippet of the finding is here:

Thank you for detailed report.

I rechecked function signature and didn't find any mistakes.

C++ type long is not platform type (x64 or x86), it is TARGET depended type, which on WINDOWS is 32 bits integer and 64 bits on MINGW

[Dominik Egert]

Ilyas #:

Thank you for detailed report.

I rechecked function signature and didn't find any mistakes.

C++ type long is not platform type (x64 or x86), it is TARGET depended type, which on WINDOWS is 32 bits integer and 64 bits on MINGW

Hi Ilyas,

thank you for checking back. I was confronted with the issue only in optimized compile builds, if optimization was off, the code ran without issue.

Interestingly, two types of errors had shown up, and it is obviously been caused by the function call to that WinAPI function.

Either, we had a leaked memory: "leaked string" - I don't even know how this is possible, but that's what MT5 reported.

Or we were facing an "Access violation". And a hard crash including a register dump.

After changing the signature as described above, both issues were gone.

So my assumption is, for some reason, the stack gets corrupted by the WinAPI function.

I hope this helps. Because, for sure, there is something not right. But I guess I cannot investigate beyond this without a significant investment.

Maybe, in case this is an option for you, you could reach out to the OP and ask for a copy of the source that produced the error, if required.

EDIT: As a sidenote: would it be possible to fix "typedef" in MQL, maybe?

[Ilyas]

Could you provide your code for investigation?

Or try this signature:

int     RegOpenKeyExW(HANDLE key,const string &sub_key,uint options,uint desired,HANDLE &result);