I am developing a DLL for a game. And sometimes I encounter errors, but to find these errors, I have to spend a lot of time searching in my code. The DLL is launched through an injector program that implements the DLL into the game process. What is the most convenient way to debug a DLL in my case?
You're on the right path by following the steps in this document.
What you need is to launch the game from the debugger, by setting it as the command line as shown in the document. Note that this won't work for all games since games typically have some kind of anti-debugger protection.
After launching the game and attaching the debugger, start your injector separately to inject your DLL into the game. Your injector should not use manual mapping or other techniques that hide or strip information from your DLL, I recommend using the good old LoadLibrary method.
For convenience, use Debug multiple processes to start the injector with the game and not have to run it manually.
If the steps described above didn't work due to the game protection, the last option is to use Cheat Engine to debug in assembly.
Related
I am interested in finding out the differences (implementation wise) between timeGetTime() and GetTickCount() Windows API functions, as the source code will not be public, I am thinking to analyse their implementation using their assembly code in Visual Studio, Can anyone suggest any better idea ?
Use a debugger, like Ollydbg, x64dbg, IDA pro or Visual Studio itself for the user-mode code.
If you need to cross over to the kernel-mode side, use WinDBG.
Make a program, as simpler as possible, that invokes the APIs you want to analyze then:
Load it in the debugger, if it is not a system-wide debugger.
Put a breakpoint on the APIs.
Run the program.
Once it breaks, single step as needed.
The more the debugger understand of Windows (read more debugging symbols it has) the easier the analysis.
WinDBG has a rich symbols library but it is a bit hardware to use.
To understand APIs like GetTicksCount you may find useful this pages:
What is the KUSER_SHARED_DATA.
How to show the KUSER_SHARED_DATA memory region in WinDBG.
Who updates the KUSER_SHARED_DATA.
KUSER_SHARED_DATA
As Peter Corders supposed, Windows exposes frequently accesses information, like the tick counts, in a memory region shared across all user-mode processes.
GetTicksCount only copy data from that (with some synchronization in place).
I'm trying to rewrite IL code dynamically at runtime. While this is quite well documented for .NET framework applications by using the Profiling API I can't find anything similar for UWP applications.
Because I have a suite of automated function tests, I need to setup the profiling environment and start a sample app programmatically.
Attempt 1
This question explains how to enable a debugger (as far as I understand a profiler is essentially a debugger) and programmatically start a UWP app.
So from my bootstrapper I call IPackageDebugSettings::EnableDebugging followed by IApplicationActivationManager::ActivateApplication.
Anyway I can't figure out how to implement the debugger. The debugger (which is an executable) is called with the following arguments:
-p 3836 -tid 6180
Both numbers change on every run. While p seems to be the process id of the debugged process, I have no idea what tid could be or how I have to use the arguments to control the debugged app (register for module load events, trigger rejits etc.).
Attempt 2
I found this issue on the Core CLR repo which is about enabling the Profiling API for Core CLR apps. The issue contains a link to a sample profiler repo.
So profiling for Core CLR apps seems to basically work the same way as it does in .NET framework apps (with some restrictions). From my bootstrapper I tried to set the appropriate environment variables (i.e. CORECLR_ENABLE_PROFILING, CORECLR_PROFILER and CORECLR_PROFILER_PATH) followed by IApplicationActivationManager::ActivateApplication.
However the profiler doesn't attach.
I'm quite sure that in general it is possible to profile UWP applications because JetBrains' dotTrace can do it.
Any ideas?
I have an embedded project which runs on a 68332 processor target (68k family). There is no OS on the target. We have a custom simulator that will allow our code to execute within Windows. The simulator is completely without our control to modify. Basically the simulator is executing the machine code which isn't very good when you need to debug. What I would really like to do is interface a debugger to allow us to debug at the source level rather than at the machine/assembly level. Has anyone ever done such a thing? Is there a spec that debuggers support? Perhaps would something like gdb work for this? Any advice is appreciated.
This is not necessarily an answer to your question - I'm not familiar with hooking up an existing 3rd-party debugger to a program executing inside a VM so I can't advise about that.
However, you control the source of your simulator so you can try implementing an interface (maybe a local socket, etc.) where your simulator keeps reporting status information about the code that's executing and links it up with source files by reading debug information from some generated debugging database. You'd likely have to support reading the debugging format of the compiler that compiles your 68k code and then use that information to link back assembly instructions to source code lines.
This way you're effectively implementing a debugger, but since you already have the simulator (a VM really), that's probably not too much of extra work - the simulator already has all state information about the executing 68k code, you just need a way to temporarily pause execution and extract state information during pause. Stepping through code after that is probably a trivial repeat of these steps.
After Google the issue i found that it was reported already but nothing useful yet from MS. I wonder if any one found a work around it?
Another option is to use windbg. You'll have to do a lot of commands by hand, but it's the best debugger out there. It handles mixed mode without any major issues. It has a bit of a learning curve, but it's very versatile.
Visual Studio's debugger is really not reliable when debugging mixed mode applications. Taken from my answer here #5965771:
If you're trying to debug a piece of native code try to use a native project as the debugger start-up application. Under the project settings, "Debugging" tab set the "Debugger Type" to "Mixed", for us this helped sometimes (the native project can be a DLL for example, simply set your main Exe as debugging target in the project settings);
OR, as already mentioned in another answer: Use WinDbg! With it you can debug both managed/unmanaged mixed code applications much more reliably.
use a different debugger, or don't use the debugger at all, just trace to a file or insert breakpoints in the code with inline assembly language.
I am talking about a small game engine using C# for game programming.
So, I have a C++ app embedding mono runtime (I call it 'launcher'). And I have an assembly written in C# which is my game engine class library. The launcher launches the assembly as it is suggested in Embedding Mono.
And now the interesting part!
The launcher implements in C++ miscelaneous functions which are exposed to the mono runtime as internal methods of my game engine classes. That is why my game engine assembly is nothing without the launcher which implements a huge part of the engine in C++.
The question: How am I supposed to debug my C# assembly? And what is more important, how am I supposed to debug a Game which I am going to write in C# ???
As you understand I cannot debug the assembly using MonoDevelop Debugger because it won't receive internal C++ implementations of some of its methods.
What I need is to run the Launcher. The launcher then will launch C# assembly using embedded mono runtime. And then I need something to connect to the launched assembly to allow its debugging.
Or any other way. Thank you!
I recommend using the Mono Soft Debugger. It's been included in the Mono runtime since Mono 2.6, and is more reliable than the old hard debugger, and also much more portable.
The Mono soft debugger can be started by passing options using the --debugger-agent commandline argument to the Mono runtime. This can be done from an embedding host by constructing a fake set of commandline arguments and passing it to mono_jit_parse_options. For example, the Moonlight browser plugin uses the debugger agent values from MOON_SOFT_DEBUG environment variable if it is set.
Typically debugger options are something like
--debugger-agent="transport=dt_socket,address=$ADDRESS:$PORT"
which will cause the app to try to connect to debugger listening on the given address, and pause until it establishes a connection. Note that the connection is established over TCP/IP, which means remote debugging is very easy to set up, and even on the local machine you would use localhost. Additional options are documented on Mono's man page.
The other piece you need is the debugger GUI/controller, to listen for the connection from your app, and handle stepping/visualizing, etc. I would suggest using MonoDevelop. There's a library for the debugger wire protocol called Mono.Debugger.Soft.dll, but it's fairly low-level, and although Mono Tools for Visual Studio supports connecting to the soft debugger, it's not yet extensible in a way that would allow debugging Mono embedding hosts.
Using MonoDevelop to accept debugger connections from embedding hosts currently requires creating an addin, but this is fairly straightforward. Take a look at the Moonlight debugger addin for an example. For simple use cases I would suggest that you don't define a whole new project type but just create a debug handler that handles existing DotNetExecutionCommand projects, so you can run->run with...->your custom debugger.
The monodevelop-list mailing list is a good resource if you have more questions.
Make use of network debugging.
You could use the Soft Debugger to debug the Mono parts, and then use remote debugging for the C++ parts.