For reference, how MultiByteToWideChar behaves depends on if the MB_ERR_INVALID_CHARS flag was set or not. If it's not set then invalid characters get replaced by the unicode replacement character (U+FFFD). Worst case scenario would be that, for example, the library you call opens a different file than the one that your expect. This could potentially be part of a malicious exploit chain if the circumstances are right.
For what it's worth I do want to emphasise how incredibly rare it is for the OS to give out unpaired surrogates. Sure the kernel doesn't validate UTF-16 wide strings but that string had to have been given to the kernel somehow. Windows handles decoding/encoding of "narrow" strings (UTF-8 or otherwise) or the program knowingly does their own translation from input (keyboard strokes, files, network streams, hard coded strings, etc) to wide strings.
So there are very very few ways to accidentally pass in an invalid string. And if it does ever happen, the user would likely want to know about the corruption so they can fix it (or figure which malicious actor is responsible for it).