I am trying to understand how the PE works under windows and so am going down the route of writing a packer.
So I took the address of entry point, that points to _mainCRTStartup and replaced it with a value that points to a "jmp _mainCRTStartup".
When I run it under a debugger my program runs fine but if I just launch the executable without a debugger it crashes and I am unable to attach a debugger post crash, the debugger says that it failed to attach to the crashing process.
I guess my questions would be: Should my approach work? If so what can I try to fix this issue?
Thanks,
Max
It turns out everything worked fine, I forgot to handle an exception in an anti-debug routine that would crash the exe if it wasn't ran in a debugger.
Related
I was trying to debug a Python program using PyCharm's debugger and each time I resumed execution after hitting a breakpoint my program exited with an obscure error (this particular program is based on Twisted and the error was about not being able to stop an already stopped reactor). The program ran fine within the debugger as long as I didn't stop it with a breakpoint, and it ran fine outside the debugger.
This problem started occurring sometime in the last weeks/month, but in the past I have been able to debug this same program without issue.
It turned out that I just had a function call expression in the PyCharm debug pane that was getting evaluated whenever I hit a breakpoint and that function had a nasty side effect. It was left over from a debugging session several weeks ago related to a shutdown problem (so it kind of makes sense). I pulled a small amount of hair over this, and didn't find anything with google, before I noticed the problem. I hope someone else can learn from my mistake.
I wrote a simple code in Ocean API. When i want to start it without debugging it works and i can see the plugin in Petrel. However when i try to debug it a message appears:
cEngineer.dll A debugger has been found running in your system.Please, unload it from memory and restart your program.
Error- Debugging Mode
How can i solve this issue?
Many Thanks,
Petrel cannot be started in Debug mode. You can attach the debugger to it after it is launched. One trick to get the debugger attached early in your plug-in code is to place:
Debugger.Launch();
in your IModule.Initialize method.
The 64-bit version of Petrel is hardened against reverse engineering during initialization, but the previous answer is correct: attaching later (e.g. with Debugger.Launch(), or manually after the UI has appeared) works fine.
Alternatively, you can use the developer-only 32-bit build of Petrel (check the Ocean developer site). Pure .NET-based plugins will work fine, and it can be launched directly in the VS debugger.
I am using Oculus World Demo.
I can start it manually, but I have an internal error during "Debug"/"Release".
How to debug such errors?
Where can I see the command which runs the program.
Again:
It runs normally when I click on MyGreatestApp.exe in folder /Debug/.
It has an internal error of used DLL, when I start it in VS2103. (something like -3003 or fffff447)
P.S. I find it strange that I can debug in "Release" mode.(I mean step-by-step program execution.) Is it normal? Maybe I do it wrong? Thanks!
It could be useful if you say in what line the program crash.
Anyway you can use the Oculus Debug Tool: https://developer3.oculus.com/documentation/pcsdk/latest/concepts/dg-debug-tool/
To record logs and see at the Runtime side what is happening.
This is error -3003, check why your application is not connecting to Oculus. I should check if I running the 64 bit of my application or something like that.
ovrError_ServiceConnection = -3003, ///< Couldn't connect to the OVR Service.
Hope it helps
I'm working on writing an OS and I'm running into problems trying to debug my code. I'm using GDB to connect to Bochs' GDB stub to "remotely" debug my kernel. Connecting works fine, as does loading debugging symbols from the kernel file. I set a breakpoint for the kmain function, which is successfully located, and the debugger breaks correctly (inside my kernel). However, I can't "step" or "next" through my code, nor can GDB apparently determine which line of code is the current line.
When I try to "step", I get the following message: "Cannot find bounds of current function". This is the only error message I get at any point.
My code is being compiled in GCC with the -g flag (I've tried other types of debugging information using GCC options; none have worked.) I have tried looking through the GDB manual , as well as searching for the answer, and I'm totally stumped. Any help would be amazing.
Thanks!
Well, I got debugging working, but I had to switch emulators. I was able to get GDB working with Qemu, even though I also had problems doing that. To get GDB to connect to the Qemu gdbserver, I had to pass the following option to Qemu: "-gdb tcp::1234,ipv4". Took me forever to figure that out... Debugging works perfectly now!
Googling throws up "This is because when you attached to gdbserver, the process under
debug has not completed the C start-up code" http://www.cygwin.com/ml/gdb/2005-03/msg00237.html... http://www.bravegnu.org/gnu-eprog/c-startup.html describes the process for when you are coding for embedded devices, maybe this will help?
If you find the answer please post here as I'd like to know what the solution to the problem is too.
I don't know why but bochs with gdb-stub enabled seems to be picky with the config options. On some system following options will break it:
--enable-x86-64, --enable-vmx
I'm trying to debug and resolve some issues with a Win32 macro application written C++ however I'm having the strangest issue.
I have to launch a 16-bit program and then simulate entering data into and have been using ShellExecute for over two years now. I haven't touched this actual code at all, but now it doesn't work.
I'm doing ShellExecute(NULL, "open", exe_path.c_str(), NULL, "", SW_SHOWDEFAULT);. This has worked flawlessly for years but all of sudden, it stopped working. It gives me an ACCESS_DENIED error code. I've Googled and apparently this is a pretty common issue with launching 16-bit apps.
The workstation XP SP2 environment hasn't changed at all, and it was actually working until I rebuilt a little while ago (I've rebuilt it before many times).
The code is inside a window procedure function and when I take it out and launch the program in the WinMain function it works, but the code has to be in the window procedure...
I've tried numerous alternatives but they all give the same issue.
The biggest issue with this is it was working then all of a sudden decided it wasn't going to with no change to both code and environment! In fact, it was about half way through testing changes that it thought it'd stop working.
Please help as I cannot do anything without the program launching. It's the first step in the code that I'm debugging!
I've discovered the issue. I changed the lpDirectory parameter (of which I was supplying NULL or "") to the directory of the executable, using the PathRemoveFileSpec() function.
The application is launching again. Now I can continue fixing the rest of the program!