Write your own windows debugger

After downloading and installing VS Code , install Node. Upon registration, you receive the publisher name that you'll need when generating an extension below.

The cool thing about VS Code is that you won't need any coding at all to add these features! Everything can be made via configuration. Let's get started. If you're on macOS or Linux and you don't have permissions to run the command above, try prepending "sudo " to the command above. As a type of extension, select the New Language Support option see Figure 1. For the publisher name, select the name you used when you created the Visual Studio Team Services account. The files that define the grammar have the.

This grammar is also used for syntax highlighting. Writing such a file from scratch is quite an exercise. Once the language support is created, the cs. To make it work for CSCS, you have to do a few changes there. First of all, rename the cs. Then open this file in VS Code, and replace of the occurrences of. See Listing 1 for details. You also need to add the new language definition in the package.

You add the CSCS language definition to the contributes part of package. The language-configuration. Basically, it contains definitions of opening and closing braces, brackets, quotes, comments, etc. This is, for instance, how the language comments and brackets are defined:. If you want to introduce a new comment or bracket type, the language-configuration. That's it! With just these few configuration changes, you already have an extension that supports syntax highlighting!

If you want to see the newly created extension in action, switch to the Debug view by clicking on the debug icon on the VS Code left-side panel and then press the gear icon. A new instance of VS Code is opened. This new instance is now aware of the extension and the new syntax highlighting should be shown for all files with the. To see the newly created extension in action, click on the debug icon on the VS Code's left-side panel and press the gear icon.

It probably doesn't make much sense to publish an extension supporting only syntax highlighting, because you're going to develop some other language features as well and you can include the syntax highlighting together with other features.

REPL read eval print loop is an interactive computer environment that permits evaluating simple user inputs and returning the results. Usually the user selects some parts of the code and sends it for evaluation. If nothing is selected, the whole line is sent for evaluation.

The cool thing about REPL is that you can even select a commented-out statement and send it for evaluation! You'll see that it's easy to adjust for any other language of your choice. First, you again use the yo extension generation tool that you used in the previous section. This time, you choose the extension type New Extension TypeScript this is the default extension type.

Now you can open the newly generated extension folder in VS Code. The first task is to create a new command, which will send the REPL request for evaluation. Most of these types of tasks are located under the contributes section in the package. Let's call the REPL command extension. This can be done in the contributes section of the package.

You also have to tell VS Code when the extension will be activated. This is done in the activationEvents section of package. One of the very important sections of the package. You add new packages to that section and after any change, you must run the npm install command in the project folder directory. Take a look at the full contents of the package. The programming language of the extension that you chose is TypeScript. The beauty of the VS Code extensions is that the actual functionality implementation can be in any language.

Then it sends these commands to the REPL evaluator, which will do the actual work and communicate the results back to the extension. I decided to implement the communication between the extension and the REPL evaluator via sockets.

Concurrent namespace. The main advantage of this class is that it provides a thread-safe way of enqueueing items to a specified queue and dequeueing them from there, so that we don't have to concentrate on these low-level details.

In case the evaluator runs on Unity, there's no need to schedule running code on the main thread because Unity calls the Update method on the main thread every frame.

At the end of the Update , you can process all of the queued requests. In case of a console application, or when the evaluator doesn't need to run on the main thread, you can process all of the requests on the same thread. I implemented the above three scenarios. Obviously, there are many more scenarios when the code needs to be run on the main thread that you may want to add. For instance, if you want to evaluate code on the Windows Phone main thread, you schedule the call as follows:.

The DebuggerServer class is implemented in Listing 3. I'll review it shortly. The server is started either asynchronously via calling StartServer or as a blocked call to StartServerBlocked. The server initializes server sockets on the configured port by default, it's and starts listening for the incoming connections:. For each accepted connection, the server runs the RunClient method, which will be started in a new pool thread.

On the other hand, it starts another thread that consumes this queue in the ProcessQueue method. For this event processing, we use the ' LoadDll ' member of the union. This debug event is generated whenever a new thread is created in the debuggee. To get information about this event, we use the ' CreateThread ' union member.

Using this member to intimate the user is straightforward:. The ' lpStartAddress ' is relevant to the debuggee and not the debugger; we are just displaying it for completeness.

It is received only for the subsequent thread creations in the debuggee. This event is raised as soon as the thread returns, and the return code is available to the system.

Of course, this event occurs when a DLL is unloaded from the debuggee's memory. But wait! The debuggee may call LoadLibrary multiple times, and thus only the last call to FreeLibrary would raise this event. It means, the implicitly loaded DLLs will not receive this event when they are unloaded, when the process exits. You can verify this assertion in your favorite debugger!

As you can see, only the base-address of the DLL a simple pointer is available for us to process this event. We can use the map or another data structure you like to store the name of the DLL against the base-address of the DLL.

This is one of the simplest debugging event, and as you can assess, would arrive when the process exists. This event would arrive irrespective of how the process exits - normally, terminated externally Task Manager etc. As soon as this event occurs, we also end the debugger-loop and terminate the debugging thread.

For this, we can use a variable to control the loop the ' for ' loop shown in the first page , and set its value to indicate loop termination. Please download the attached files to see the entire code. This is generated whenever an exception occurs in the process being debugged. Possible exceptions include attempting to access inaccessible memory, executing breakpoint instructions, attempting to divide by zero, or any other exception noted in Structured Exception Handling.

This structure describes the exception that caused the debugging event. This debugging event needs a separate article to complete it fully or partially! Thus, I would discuss only one type of exception event, along with an introduction to this event itself. The member variable ' Exception ' holds the information regarding the exception just occurred. The ' ExceptionRecord ' member of this structure contains detailed information regarding the exception.

The detailed information is put into this sub-structure, because exceptions may appear nested, and would be linked to each other in a linked-list manner. It is out of topic for now to discuss nested exceptions. Disassebmly and dumping however is not supported internally on windows, so we would have to use a 3rd party library or write our own functionality if we wanted to do this. Debugging on the other hand is easy.

Step 3 — getthreadcontenxt and store in structure- Windows api which stores the registers eax, esi, etc. Step 6 — Handle the debug loop. So I decide to print a error message and skip it. As my project is not fully tested, I have never encountered such a situation. When the debuggee calls the OutpuDebugString function, it will raise this debug event.