I am trying to open a simple Hello World program written in c++ in x64dbg and I get an error "Invalid PE File". The file loads fine in IDA. What might be the problem ?
Author of x64dbg here, the error you're experiencing is misleading and has nothing to do with the validity of the PE file. It simply means that CreateProcess failed for your file. This can have various reasons, once of which is the validity of the PE file. Get the latest version from here for a better error message.
Validate the process starts correctly outside of the debugger and make sure it is not blocked by for example your anti virus software.
Related
I'm trying to read a a XML file with C++ using xercesc. It compiles OK, but when I try to excecute the app (and read the XML), I get this error:
Could not open catalog:
XercesMessages_en_US.cat or
XercesMessages_en_US.cat
Cannot load message domain
Someone knows what this means?
I answer myself:
As the error says, xerces is unable to find XercesMessages_en_US.cat, wich is a file located in /usr/share/xerces-c/msg/ (in my case, gentoo linux).
To solve it, just need to write in a bash:
export XERCESC_NLS_HOME=/usr/share/xerces-c/msg/
Then, it will find it.
In my case, I wrote this in .bashrc so it is exceuted in every start.
I'm trying to get the output of an exe in python (called: ibstat.exe).
As this exe is on an external server, I got one possible output and used it to make a mock-object. (As I don't know how to create exe-files I made a ibstat.py mock-object.)
When I was done writing and testing my programm locally on my computer, I went back to the external server to test it again there. But I got this Error message:
SyntaxError: Non-ASCII character '\x90' in file hello.exe on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details"
I used this to get the output of the exe-file:
subprocess.check_output([sys.executable, "ibstat.exe", "34"])
when this didn't work I also tried:
subprocess.call([sys.executable, "ibstat.exe"])
subprocess.Popen([sys.executable, "ibstat.exe"])
On my computer when I was opening ibstat.py everything was working just fine (with call, Popen and check_output).
And executing ibstat.exe on the server in the command-shell works too.
Questions:
Is there anything I overlooked/I forgot to do/try?
What can I do to open the exe properly without getting the
Syntaxerror?
Do I need to clarify my question more clearly, or is more
Information needed?
Removing sys.executable SOLVED the issue.
I am trying to process a binary file generated by a PSI DRS4 for work. I tried this using a C++ code given in the src folder of the software used to run the board.
A friend of mine compiled and executed this code on his linux computer just fine. I wanted to adapt this code to windows. I went through the compilation step pretty easily but then when I try to execute it, it just crashes...
After some further investigation, what I understand is that the header(s) cannot be read properly (probably leading to the crash when they're supposed to be used later in the code)
I thus tried to read the file with HexEditor Neo and here is what I get: screenshot binary file Hexeditor
As you see the part after EHEADER becomes unreadable... Is it normal? Has anyone faced this situation before ?
After the program I am debugging crashes, I am left with heap dump *.mdmp file & appcompat.txt in my Temp directory. I understand that appcompat.txt is an error report. Is there a description of its format?
My appcompat.txt lists a number of DLLs. Am I correct assuming that the reason for a crash could have only come from one of the listed DLLs? Can I limit my debugging effort to the DLLs listed in appcompat.txt?
Thanks in advance!
The minidump file is far more informative for diagnosing crashes:
Install Debugging Tools for Windows, if you don't already have it.
Set up the symbol path variable _NT_SYMBOL_PATH to point to the Microsoft symbol server
Run Windbg and do File -> Open Crash Dump and locate your .dmp or .mdmp file
Type !analyze -v.
This will try to isolate the location of the crash. Note that just because a crash occurs in a particular dll it doesn't mean that is where the bug resides - it could be because an invalid parameter has been passed in from your application code. The analysis should hopefully show you a meaningful stack and an error code which should help in working out the actual cause of the crash.
I already asked this question in the nvidia forum but never got an answer link.
Every time I try to step into a kernel I get a similar error message to this:
__device_stub__Z10bitreversePj (__par0=0x110000) at
/tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c:10
10 /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c: No such file or directory.
in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c
I tried to follow the instructions of the cuda-gdb walkthrough by the error stays.
Has somebody a tip what could cause this behaviour?
The "device stub" for bitreverse(unsigned int*) (whatever that is) was compiled with debug info, and it was located in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c (which was likely machine-generated).
The "No such file" error is telling you that that file is not (or no longer) present on your system, but this is not an error; GDB just can't show you the source.
This should not prevent you from stepping further, or from setting breakpoints in other functions and continuing.
I was able to solve this problem by using -keep flag on the nvcc compiler. This specifies that the compiler should keep all intermediate files created during the compilation, including the stub.c files created by cudafe that are needed for the debugger to step through kernel functions. Otherwise the intermediate files seem to get deleted by default at the end of the compilation and the debugger will not be able to find them. You can specify a directory for the intermediate files as well, and will need to point your debugger (cuda-gdb, nsight, etc) to this location.
I think I had such problem once, but can't really remember what was it caused with. Do you use textures in your kernel? In that case you couldn't debug it.