I wrote the code for WSPE.dat and can confirm that I custom wrote the encryption based on the supplied name/key plus the 'invalid' PE heading. So, if a user attempts to modify the PE heading on the drive to allow for debugging of the DLL for a dump then it'll fail to properly decrypt in memory.
The best way to debug this in my opinion is to use WinDbg from Windows SDK or WinDbg Preview from Windows Store. In Windows it is not possible to attach two debuggers to the same process. WinDbg supports easily debugging .NET and native processes.
To access .NET functionality you can run commands:
.loadby sos clr
More details of the .NET extensions here
One way is to patch the bytes on IDA, and create a diff file. Use it to change the binary.
Another way that is useful in averting some verification techniques is to generate an executable on runtime from the current memory dump(after you applied patches).
This way the program will start from a certain state that you can set.
Ollydbg had this plugin. I am ...