I did not have the latest release of WinDbg but while debugging a 32-bit EXE, adding the WinDbgx64 directory to the PATH environment solved this problem.
I solved this problem by configure the window PATH environment variable to point to the WinDbg64 for and not the x86 version.
Thanks This Two Answer is helpful for me
x64dbg can load the pdb and list all the function names if you have pdb for your executable
view->modules->download symbols for this module
also x64dbg can use the source file (ctrl+shift+s)
just for completion sake windbg usage
:\>cdb -c ".lines;bp `winchk.cpp:17`" winchk.exe
Microsoft (R) Windows Debugger Version 10.0.17763.132 AMD64
I found the cause of the crash which is... Themida 🤦♂️
What happens is that from build 1607 and higher some exports have a double redirection using api sets. The app imports a couple of functions from Usp10.dll which have an apiset redirection to Gdi32.dll and inside Gdi32.dll there is an apiset redirection to Gdi32full.dll.
Themida "understands" ...
You can start with static analysis. Dump the file at runtime and see what you can gather from the dumped file. You can rebuild the import table with tools like Scylla. Generally, the above reconstructed file is pretty good for analysis already. Since you mentioned files relating to gdi32.dll, reconstructing the import table would do you good.
If it is not ...