Motivation
Main reason for writing this blog-post is the extremely crappy article by Vallejo named "Installation and First Contact With the New WinDbg". I read it, cried for a few minutes and decided to fix it.
Mandatory XKCD reference:
Having said that, let's go through some of the most "brilliant" Vallejo's statements!
Installation
We execute WinDbg from installation shortcut and we search the main process.
Dude, when your article is called "Installation and first steps..." shouldn't you start at the beginning and tell us where to get this app and how to install it?
You need to get the app from the Windows Store: https://www.microsoft.com/store/apps/9pgjgd53tn86.
No, there is no real technical reason for that, just another attempt of Microsoft to convert you to Windows 10 and make you use their Windows Store.
To make matters worse, you need to have installed the latest and greatest update of Windows 10 to do that. There is no technical reason for that, either.
After you've jumped through all those hoops, you get this nice and shiny Windows Store app. Windows Store apps get installed under "C:\Program Files\WindowsApps\" and this one is no different. At the moment of writing the application version was 1.0.16, so it got installed into "C:\Program Files\WindowsApps\Microsoft.WinDbg_1.0.16.0_x86__8wekyb3d8bbwe".
Reparse point
The installation creates another exe here: C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\WinDbgX.exe. It is zero bytes, and if you try, for example, to copy it, you can’t.
Because it's a reparse point, not an EXE file.
Windows 10 processes bundled Windows Store application's AppxManifest.xml and creates appropriate appExecutionAlias'es:
.run
.dmp
.mdmp
.hdmp
.kdmp
.ndmp
Same thing goes for all other applications Vallejo "found" under C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\, like dbgsrv64.exe:
You can read more about aliases on MSDN: Start your app by using an alias.
Fsutil
I have not found a tool or way to manage or get information about these files.
Ever tried fsutil? It's been part of Windows since Windows7.. 😀
Here's output of fsutil reparsepoint query WinDbgX.exe:
As you can see, it's a reparse point with a tag 0x8000001b (IO_REPARSE_TAG_APPEXECLINK).
Sure, you can Google for that - but it won't tell you much, except that it's not really documented and should be left alone.
Command-line
Old windbg.exe accepted parameters with “-“, for example -k. New Windbg needs /k parameter to pass the connection configuration
Bullshit! In fact, WinDbgX accepts any of 4 different delimiters: "-", "–", "—", "/" and combinations of those..
Ok, that was enough criticism for one day. Let's do something more constructive!
Running WinDbgX on Windows 7
Remember how I said that there is no technical reason why WinDbgX should be available only on Windows 10 and only as a store app? There really isn't. 🙂
Here's WinDbgX running on my Windows 7 and debugging one of the FLARE2017 crackmes:
It's actually a really simple fix.
- You need to copy all the files from your Windows 10 machine to your other machine (Windows 7 in my case). It's as simple as selecting all files in "C:\Program Files\WindowsApps\Microsoft.WinDbg_1.0.16.0_x86__8wekyb3d8bbwe" and copy-pasting them. Don't worry about the reparse points in C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\, we'll fix that later.
- If you try to run DbgX.Shell.exe on Windows 7, it will fail with Exception:
***FATAL ERROR ENCOUNTERED*** 2017-11-21:20:01:12:504 : Error : DbgX.dll : (E) System.TypeLoadException: Could not find Windows Runtime type 'Windows.ApplicationModel.Package'. ---> System.PlatformNotSupportedException: Operation is not supported on this platform. --- End of inner exception stack trace --- at DbgX.DbgEngModule.SetDbgSrvOverridePathIfNeeded(Boolean use64Bit) at DbgX.DbgEngModule.DebugCreateOutOfProc(Boolean use64BitDebugger, Boolean shouldElevate) at DbgX.EngineThread.ThreadProc() System.TypeLoadException: Could not find Windows Runtime type 'Windows.ApplicationModel.Package'. ---> System.PlatformNotSupportedException: Operation is not supported on this platform. --- End of inner exception stack trace --- at DbgX.DbgEngModule.SetDbgSrvOverridePathIfNeeded(Boolean use64Bit) at DbgX.DbgEngModule.DebugCreateOutOfProc(Boolean use64BitDebugger, Boolean shouldElevate) at DbgX.EngineThread.ThreadProc()
- Let's look at that code in DbgX.dll using dnSpy:
It's crashing on the Package.Current.Id.FamilyName, as this function is available only for Windows Store apps.As a simple hack, we can replace this call with an empty string. Better hack would be to use the proper folder based on the actual WinDbgX path. But the simple way will do for our demo..
- Using "Edit IL instructions" function in dnSpy, replace first 4 instructions with ldstr and nops:
- Save the module. If saving fails, remove read-only attribute from DbgX.dll and try again.
- Since we chose a simple hack, create folder C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\
- Depending on your OS (32- or 64-bit), copy files from WinDbgX\X86 or WinDbgX\amd64 folder to C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\. Rename dbgsrv.exe to dbgsrv32.exe or dbgsrv64.exe accordingly.
- Run the DbgX.Shell.exe shell now. It will work just fine!
There are 3 more places in DbgXUI.dll, DbgX.Util.dll and Extensions\DbgX.External.dll that might need similar fixes. But that's behind the scope of this article.
Conclusion
It is true that classic WinDbg looks really dated. So, I can totally understand why Microsoft would want to create a replacement with a better UI. However, WinDbgX falls short on everything - its installation via Windows Store is brain-dead stupid, its user interface is confusing (who would look at Model->Change Query to change debugger settings?!) and severely limited (no multiple Memory windows, seriously?). If it was a school project, it wouldn't get even a B-. But for some reason, Microsoft insists that this is the only way forward. Oh, well.. 🙁
At least, the DLLs are not obfuscated, so someone can take them and make a much better UI.. 😉
Have fun!
kao.
Thanks a lot for this ... was fun and instructive reading it 🙂
I would have not thought about reparse points (and I must admit I didn't know about this fsutil feature) ... so thanks for that too.
Best Regards,
Tony
Could you provide some guidance on what needs to be fixed in DbgXUI.dll, DbgX.Util.dll and Extensions\DbgX.External.dll?
Thanks
i found an alternative way to start windbg preview (latest as this writes) under win7 (x64).
when i tried to run "DbgX.Shell.exe" directly under win7, it crashes.
however, when i try to run "DbgX.Shell.exe" under old windbg debugging, it runs flawlessly.
however, from my testing, with this trick, it only able to debug x64 app, but not for x86 app.
now DbgXdll is changed and your fix on w7 not work:
private static void SetDbgSrvOverridePathIfNeeded(EngineArchitecture arch) { string familyName = DbgEngModule.GetFamilyName(); if (familyName == null) { return; } string path = Environment.ExpandEnvironmentVariables("%LOCALAPPDATA%\\Microsoft\\WindowsApps\\" + familyName); string value; if (arch != EngineArchitecture.X86) { if (arch != EngineArchitecture.X64) { throw new ArgumentException("arch"); } value = Path.Combine(path, "dbgsrv64.exe"); } else ...It's a 3 years old article, I'd be surprised if things did not change over time! 🙂
From a quick look, in the latest version you don't need to patch anything. Just get the correct API set DLLs and you're good to go.
Here's my updated steps:
1) Copy all files from your Windows 10 machine, folder C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2103.1004.0_neutral__8wekyb3d8bbwe to your Windows 7 machine.
2) Try to run DbgX.Shell.exe, it will show error "The program can't start because api-ms-win-downlevel-kernel32-l2-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem."
3) Get 64-bit api-ms-win-downlevel-kernel32-l2-1-0.dll from somewhere and put it in amd64 subfolder. I copied mine from Win10 machine, folder C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
4) Try to run DbgX.Shell.exe again, it will complain about missing api-ms-win-core-sysinfo-l1-2-0.dll.
5) Get all missing API set DLLs. I got mine from Win10 machine folder C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\Microsoft.NETCore.Windows.ApiSets-x64\1.0.0\runtimes\win7-x64\native
6) Run DbgX.Shell.exe and enjoy the show! Some things will probably not work, but this is enough to prove my point.. 🙂
Hello dear friend, thanks for your nice post
may i ask how should i download WinDbg Preview for Windows 7 x64 Ultimate ? the thing is there is no way downloading it its only for Windows 10, could you please guide me in this ?
One way is to install Windows 10 inside VMWare and get Windbg from there. That's what I did.
If you cannot or don't want to do that, you can always use Microsoft Store link generators. For example this: https://store.rg-adguard.net/
Enter ProductId "9pgjgd53tn86" and get download link to APPX file. It's actually a ZIP file, so you can unpack it using WinRar or any other archiver.
for x86:
put to folder "C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2103.1004.0_neutral__8wekyb3d8bbwe\x86" the dll from folder "C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\Microsoft.NETCore.Windows.ApiSets-x86\1.0.0\runtimes\" dependent on your OS.
for x64:
put to folder "C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2103.1004.0_neutral__8wekyb3d8bbwe\amd64" the dll from folder "C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\Microsoft.NETCore.Windows.ApiSets-x64\1.0.0\runtimes\" dependent on your OS.
tested on windows7 pro and windows8.1 SL both x64
Hi
Thank you for sharing this post.
I tried 2 methods that you posted and commented, but I failed both of them.
The same problem is below.
WindowsDebugger.WindowsDebuggerException: Could not load dbghelp.dll from C:\Users\user01\AppData\Local\Microsoft\WindowsApps\Microsoft.WinDbg_1.2103.1004.0_neutral_8wekyb3d8bbwe\amd64:System.ComponentModel.Win32Exception(0x80004005):The parameter is incorrect
at DbgX.DbgEngModule.LoadLibraryFromDirectory(Stringdirectory,String library)
at DbgX.DbgEngModule.LoadDbgEngModule()
at DbgX.EngineThread.ThreadProc()
Could you help me with this problem?
Thank you
Judging from error message, it cannot load dbghelp.dll.
Are you sure you copied all the correct files? One of the likely causes for such error message would mixing up 32- and 64-bit DLLs.
If you could post detailed steps of what you did, I could try to reproduce them on my test machine.
Thank you for your quick reply.
I would share what I've done with the way you commented(2021/03/16).
1. prepared 2 VM machines (Windows 10 Pro X64 / Windows 7 Ultimate X64)
2. Downloaded WinDbg version 1.2103.1004.0 with the way you commented(2021/04/21).
3. Copied all files from my Windows 10 machine, folder C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2103.1004.0_neutral__8wekyb3d8bbwe to my Windows 7 machine folder C:\Program Files\WindowsApps\.
(I'm not sure if this path would correct. Should I copy all files to my Windows7 machine folder C:\Users\\AppData\Local\Microsoft\WindowsApps\ ? I don't know the exact path so I've done under that paths and under the Desktop too, but I also failed.)
4. Tried to run DbgX.Shell.exe, it showed the same error that I've commented before(dbghelp.dll)
5. Tried to run dbgsrv.exe (~\amd64\dbgsrv.exe), it showed the error "api-ms-win-downlevel-kernel32-l2-1-0.dll" is missing from my computer. So I got this file from Google and copied it under the amd64.
6. Tried to run DbgX.Shell.exe again, it complained about missing "api-ms-win-core-sysinfo-l1-2-0.dll". So I got this file from Google and copied it under the amd64.
7. Tried to run dbgsrv.exe again, it showed the error "The application was unable to start correctly(0xc000007b). Click OK to close the application.
8. So I try to run DbgX.Shell.exe again, it showed the same error again about dbghelp.dll that I commented on before.
I'm not sure what is problem..could you give me some advice? Thank you so much in advance.
I went through all the steps again. Can you please try this shortened and clarified version?
1) Prepare Windows 7 VM. You'll need to install KB4474419 and .NET Framework 4.8. You don't need Windows 10 machine at all.
2) Visit https://store.rg-adguard.net/, enter ProductId "9pgjgd53tn86" and get download link to APPX file. You can pick any build, both 1004 and 26002 worked in my test.
3) Download said APPX file, rename it to ZIP.
4) Extract ZIP file to folder of your choice. You will be running WinDbgX from this folder.
Important: If you're using Windows Explorer to extract ZIP, you must unblock ZIP file before extracting it (Right Click on file->Properties->Unblock). Failure to do so will cause cryptic errors later.
5) Visit Nuget.org and download the package microsoft.netcore.windows.apisets-x64.1.0.0.nupkg.
6) Rename nupkg to ZIP, extract to some temporary folder.
7) In folder runtimes\win7-x64\native\ you should see 122 DLLs. Copy all of them to both your WinDbgX folder and WinDbgX\amd64 subfolder. Of course, you don't need all these DLLs. If you wish, you can cherry-pick just the really necessary ones.
8) Now, you need to find api-ms-win-downlevel-kernel32-l2-1-0.dll. One link I found on the Internet: MEGA.
Copy this file to both WinDbgX folder and WinDbgX\amd64 subfolder.
If you don't trust some random links, you can download official installer for Windows SDK and install only Debugging Tools for Windows.
9) Now you should have fully functional WinDbgX running on Windows 7.
Thank you so much!!!
I did it the way you commented and it finally worked. But one problem is that I couldn't start TTD(Time Traveling Debugging) in WindbgX. Anyway, Thank you so much for helping me!
I'm glad you made it work! Congrats!
If you're interested in using such advanced WinDbgX features, perhaps you should consider using Win10 for those debugging sessions. 🙂
TTD sounds like a very cool feature, perhaps I should finally learn to use it properly..
Yes, I think I should consider another options to use TTD 🙂
Thank you very much and I hope your everything is going well !