we have a couple of tests failing when reading child process module list with STATUS_INFO_LENGTH_MISMATCH or STATUS_PARTIAL_COPY
one tentative approach had been added to dbghelp/tests for work around it by retrying the failing API call when this happen (search for wrapper_XXX)
there's still pending areas requiring some attention (symrefreshmodulelist in dbghelp, psapi enumprocessmoduleex...)
https://bugs.winehq.org/show_bug.cgi?id=54717
one explanation could be that all the modules in the child process are not loaded yet, and the module enumeration fails on window. msdn documentation is scarce
this only interesting bit I found is here
https://learn.microsoft.com/en-us/windows/win32/api/tlhelp32/nf-tlhelp32-cre...
it reads
```plaintext For example, if the loader data table in the target process is corrupted or not initialized, or if the module list changes during the function call as a result of DLLs being loaded or unloaded, the function might fail with ERROR_BAD_LENGTH or other error code. Ensure that the target process was not started in a suspended state, and try calling the function again. If the function fails with ERROR_BAD_LENGTH when called with TH32CS_SNAPMODULE or TH32CS_SNAPMODULE32, call the function again until it succeeds. ```
this patch tries another approach by waiting until a window in the child process is visible
I ran a couple of tests for symrefreshmodulelist and couldn't get an error. we still more tries (on a longer period) to see if it's a fruitful approach or not
I also trace whether the retry mechanism is used
the tests are not changed (we just wait a bit longer for the child before testing)
if fruitful, we could remove the existing wrapper in dbghelp/test and fix psapi accordingly