I didn't know That we've got a Reverse Engineering community around here :D I am very glad on that....

anyway... I haven't used IDA Pro for quite some time, upgraded to win 10 in the mean time.

I am unable to launch debugging directly from IDA Pro. WinDbg is setup correctly, windbg attaches a process just fine on itself. WinDbg has been added to the PATH variable.

When i try to launch debugging from ida PRO,or attach I get the error:

"Could not initialize WinDgbEngine (..) %1 is not a valid Win32 application"

ideas? seems like something is wrong with parameters passing?

  • I've spent a couple of hours on this one..making me sick..anyone? – Vega4 Sep 18 '16 at 15:22
  • I have even tried to use remote debugging for a local app and its unable to cope with WInDbg.. – Vega4 Sep 18 '16 at 15:23
  • I've even downloaded another verion of windbg..older one.. is it a known issue? – Vega4 Sep 18 '16 at 15:23
  • Sounds like a similar issue I had when opening .dmp files with WinDbg. I don't remember the exact details but opening .dmp files directly with WinDbg required setting up the shell extension registry key somewhat differently. Can you open a .dmp file by double clicking it? If not, you could research that and that might also solve your issue. – Lieven Keersmaekers Sep 19 '16 at 4:52

ok, I've found a solution please note that you need to couple your IDA with an appropriate version of x86 windbg... latest release of WinDbg wont work.


Normally, to solve that problem in WinDbg, I just have to run the Debugger as Administrator, and the (%1 is not a win32 application) message goes away when I use Open dump file with WinDbg. It only happens if you try to double click a dump file without having the correct permissions. I know it's pretty basic, but always run IDA Pro or WinDBG as administrator and that message should not appear.


I solved this problem by configure the window PATH environment variable to point to the WinDbg64 for and not the x86 version.


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.

Works as well with remote Windbg.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.