Support loading dump

[Zhentar]

The main obstacle I've encountered consuming DbgProvider from a standalone C# application is that the only static public DbgEngDebugger method is for remote targets. A secondary challenge was that after loading the dump file, DbgEng was not in a usable state until I waited on WaitForEventAsync and then called GetCurrentTarget.

This pull request adds new methods to address both issues. It also updates CreateProcessAndAttach to mirror them, since DbgShell is only using CreateProcessAndAttach2 itself.

[jazzdelightsme]

Thank you for your contribution! I will take a look.

[jazzdelightsme]

    public void LoadCrashDump( string dumpFileName,

The names LoadCrashDump and OpenDumpFile are so similar... it would be difficult for somebody to know which to choose.

The difference is that OpenDumpFile is a superset of what LoadCrashDump does. Do you think there is a scenario where somebody would want/need to call just LoadCrashDump instead of OpenDumpFile?

If not, maybe we could just make LoadCrashDump internal, and for bonus points, OpenDumpFile could call LoadCrashDump instead of duplicating it. It's only two lines of code, and it would be slightly less efficient (it would check and see that it's already on the dbgeng thread), but the advantage is for readers/maintainers of the code, seeing the relationship of what the two do. #Closed

---

Refers to: DbgProvider/public/Debugger/DbgEngDebugger.cs:54 in dd27b7b. [](commit_id = dd27b7b4d7c314b503a7e6873cff35b658ee5d0a, deletion_comment = False)

[Zhentar]

Internal LoadCrashDump seems like the right choice to me 😄

[Zhentar]

Are there any other changes you'd like me to make on this outstanding?

[jazzdelightsme]

No; sorry--I got stuck in a malaise of not having a solid direction for library use and then got distracted.

Thank you for contributing!