Ephraim,

When you say "corrupted" to better understand...
- Did you try to mount the DB (from the SMP of with ^MOUNT)? Sometimes if IRIS/Cache was "forced" than a *.lck file on the DB folder need to be deleted in order to allow a successful mount. 
- If the DB is mounted, did you got a <DATABASE> (or other) error? if so, then what was said using ^Integrity and ^Repair could help - but only if you fully understand how to use those tools (!) Most of the time, a corrupted DB is fixable using those tools, or at least data can be 99% recovered. Depending on the number of errors: if its huge than sometimes it is faster to recover the DB from a valid backup + journal files. 

BTW - if this is a mirrored DB than there are other considerations as well. 

Happy new year!

@Jeffrey Drumm have you able to solve this ?

We are having the same problem.
We have the IRIS internal apache webserver configured to have HTTPS access, with self-signed certificate.
Connection to the SMP portal is working fine with HTTP and HTTP.
When we tried to "force" HTTPS only (by doing a HTTP->HTTPS redirect on apche level) we are not able to connect with VS-code: we get the same error: "unable to verify the first certificate".
We tried to uncheck the "Http: System Certificates" and "Http: Proxy Strict SSL" but this was not solving the problem.

Currently, the only workaround I see is to disable the redirection, but with this solution we will still having (even by mistake) HTTP traffic to the server, which we want to aviod.

Any idea ?

On a given machine any process can run "as fast" as the CPU clock rate (higher = faster = more operations/sec.)

It is true that a single process can do approx. 15-20 MB/sec. (depends on the CPU clock rate & the disk type: SSD, Premium SSD, Nvme)

The best way to overcome this limitation is do to a "heavy I/O" processes in parallel using the queue manager.
On machines with 16/32 cores, you may achieve your "infrastructure limits" (160MB/sec) easily and even more (we managed to go to a 1000MB/sec of Nvme disks)

Yes, you have also journal files...  they keep all the changes (set, kills, start/end transactions) made to the DB (after actual write to the DBs) and also to be able to roll back transactions.

The write daemon and the WIJ file is more to keep DB physical "integrity" in case of a failure, and its before actual data is being written to the DBs

I see you are using windows. So just look at the windows "task manager" for the "active time" of the disk D:\ If you see that there are times that you hit the 100% "active time" then move the WIJ to a different disk. This will improve performance.