If IVs are predictable and inputs are influenced by attackers (ie, attackers get a degree of chosen plaintext), attackers can mount a byte-at-a-time decryption attack a la ECB mode; this is what the BEAST attack did. I don't know that this is plausible with Random(), but why even make people wonder? What was the logic behind dropping to an insecure RNG for a random crypto parameter?
It sounds like you're also building a system from scratch that doesn't have forward secrecy. Why don't the parties arrange for temporary secrets and use the public keys solely to ensure that they've securely agreed on them? The system you've built is less secure than OTR, which is widely implemented and already has libraries that work on WinAPI.
Crypto RNGs take a toll on the system as they can drain the entropy pool. There are attacks that involve draining entropy pools, which can be mitigated to some extend by only using crypto RNG when necessary.
Why do you say there is no forward secrecy? Every single message is encrypted with a new key, so the only viewers are the folks the message is explicitly sent to.
You say this is less secure than OTR, but I fail to see why. I'd say the reverse is true.
Also, in IronPigeon attackers don't get any degree of chosen plaintext or ciphertext except for keys that are one-time use only, so the attack is moot.
None of the crypto models I've ever read about assume that IV is anything more than nonce quality. In fact in many implementations the IV is given as the first block of a ciphertext (not encrypted itself), so it's hardly treated as a secret, therefore any predictability is harmless.
It sounds like you're also building a system from scratch that doesn't have forward secrecy. Why don't the parties arrange for temporary secrets and use the public keys solely to ensure that they've securely agreed on them? The system you've built is less secure than OTR, which is widely implemented and already has libraries that work on WinAPI.