Good day to you!  My name is Stanislav and I like to write code. This is my first english article on Habr which I made due to several reasons: This article is an english version of my very first article on russian. Let me introduce the main figures in this story who actually fixed the bug preventing Git from running in ReactOS — the French developer Hermès Bélusca-Maïto (or just Hermes with hbelusca nickname) and of course me (with x86corez nickname). The story begins with the following messages from the ReactOS Development IRC channel: Since ReactOS target platform is Windows Server 2003, Git version 2.10.0 was chosen for the investigation — it's the last one supporting Windows XP and 2003. Testing was done in the ReactOS Command Prompt, external symptoms of the problem were rather ambiguous. For instance, when you run git without additional parameters, it displays the help message in the console without any problems. But once you try git clone or even just git --version in most cases the console just remains empty. Occasionally it displayed a broken message with an assertion: Fortunately git is an open source project, and it helped a lot in our investigation. It was not too hard to locate the actual code block where unhandled exception happened: https://github.com/git-for-windows/git/blob/4cde6287b84b8f4c5ccb4062617851a2f3d7fc78/exec_cmd.c#L23 And argv0_path variable value is assigned by this code: Once I obtained all this information I've sent some messages to the IRC channel: The variable name suggests that the actual value is derived from argv[0] — usually it contains the executable name in zero index. But subsequently everything was not so obvious... After that I decided to compile git straight from the source, so I'll be able to print variables of the interest "on the fly" directly to the console. I've followed this step-by-step tutorial and in order to compile compatible git version I've selected this branch: https://github.com/git-for-windows/git/tree/v2.10.0-rc2 Setting up mingw32 toolchain went smoothly and I just started building. However almost always there are undocumented pitfalls in such step-by-step tutorials, and I immediately encountered one of them:  Through trial and error, as well as using hints from the hall (IRC channel), all compile time errors were fixed. If somebody wants to follow my steps, here is the diff to make compiler happy: https://pastebin.com/ZiA9MaKt In order to avoid calling multiple functions during initialization and to reproduce the bug easily, I decided to put several debug prints right in the beginning of the main() function, which is located in common-main.c in the case of git: I've got the following output: One can assume everything is fine here, argv[0] value is correct. I've got an idea to run git inside the debugger, OllyDbg for example, but something went wrong... And right here sanchaez suggested an excellent idea that shed light on many things!  Assertion no longer occurred, and git successfully printed its version. The case moved from the dead center, and I tried different ways to run git in the command prompt, and found the right way!  The problem was clearly that git expected the full path on the command line. So I compared its debug output on Windows. The results surprised me a bit.  For some reason argv[0] value contained the full path to the git.exe binary. Hermes suggested to check whether ReactOS cmd.exe is a guilty component here...  But this screenshot confirmed that the actual problem is somewhere else. The last option was to test ReactOS msvcrt.dll in Windows. I tried to place the file in the same directory where git.exe is located, but it didn't help. Mark suggested to add an .local file: But for some reason this method did not work either. Perhaps the fact that I did all the experiments on the server edition of Windows (2008 R2). The last idea was suggested by Hermes: So I replaced all occurrences of msvcrt in git.exe with msvcrd using WinHex, and renamed ReactOS msvcrt.dll accordingly, and here we are:  bug becameNow we hit the same assertion, but in Windows! And that means the source of our problems is in the one of ReactOS msvcrt functions. It's also worth to note that the assertion message is displayed correctly in Windows. So, to solve the actual problem, we had to find the API function in msvcrt which gives the full path of the current application. I googled a bit and assumed the problem is with _pgmptr function. Hermes sent a link to the patch, I manually applied it and rebuilt the system, and after these moves the original problem magically disappeared!  That said, another bug that indirectly prevents ReactOS from building itself has been fixed thanks to collective efforts. The funny coincidence is the fact that not long before another bug was fixed in the same msvcrt dynamic library (namely, in the qsort function) which did not allow to compile the USB drivers in ReactOS. I participate in the development of many projects written in different programming languages, both closed and open source. I'm contributing to the ReactOS project since 2014, but I began to actively help and actually write code only in 2017. It's especially interesting to work in this area because it's an entire operating system! You feel a huge scale of the result in which the efforts were invested, as well as a pleasant feeling that there's one less bug! :) Someone may wonder why I'm contributing to ReactOS and not Linux for example. So historically in most cases I write programs for Windows and my favorite programming language is Delphi. Perhaps that's why the architecture of Windows NT together with the Win32 API is very interesting to me, and the ReactOS project of the free Windows alternative makes the old dream come true — it allows you to find out how everything works under the hood in practice. I hope you enjoyed my first english article here. I'm looking forward to your comments! Программист