Found while debugging a crash in Proton. I don't think this is the cause of the crash, but the code here looks wrong.
In the call to EnumProcessModulesEx here:
|
EnumProcessModulesEx(_handle, &moduleList[0], static_cast<DWORD>(moduleList.size()), &numModules, 3); |
According to MSDN, the array size passed in and returned to moduleList should be in bytes. The code correctly (but confusingly given the naming) divides numModules by sizeof(HMODULE) before using it, but it doesn't convert the element count returned by vector.size to a byte count. So if I'm reading this correctly, instead of the 1024 module handles it allocates memory for, it only requests 128 of them.
I would also suggest checking the return value of EnumProcessModulesEx - since I know from a stack trace that something is going wrong around this time, it'd be good to have some indication if that's failing for some reason.
I don't think this is causing the crash I'm seeing because it specifically crashes reading moduleList[i], which should still be in range of the allocated memory, unless there is an absurd number of modules loaded in the target process, or EnumProcessModulesEx fails without assigning a value to numModules, and an undefined value is used. I'll keep working on that.
Found while debugging a crash in Proton. I don't think this is the cause of the crash, but the code here looks wrong.
In the call to EnumProcessModulesEx here:
The-Witness-Randomizer-for-Archipelago/Source/Memory.cpp
Line 94 in 189a3a5
According to MSDN, the array size passed in and returned to moduleList should be in bytes. The code correctly (but confusingly given the naming) divides numModules by sizeof(HMODULE) before using it, but it doesn't convert the element count returned by vector.size to a byte count. So if I'm reading this correctly, instead of the 1024 module handles it allocates memory for, it only requests 128 of them.
I would also suggest checking the return value of EnumProcessModulesEx - since I know from a stack trace that something is going wrong around this time, it'd be good to have some indication if that's failing for some reason.
I don't think this is causing the crash I'm seeing because it specifically crashes reading moduleList[i], which should still be in range of the allocated memory, unless there is an absurd number of modules loaded in the target process, or EnumProcessModulesEx fails without assigning a value to numModules, and an undefined value is used. I'll keep working on that.