Call analysis failed: what can I do?
Ah yes, another question that desperately needs a TL;DR and is only documented on Igor Skochinsky's blog.
Happens all the time.

Warning! For ease of display, all screenshots operate on an x32 binary! The caveats of x64 are described in each step individually.

ADHD mode
1. Find the faulty call instruction by double-clicking the address in the output console
2. Check callee function's type by clicking on its name and pressing Y
3. Is it populated? Erase everything, press Enter and try again
4. Didn't work/it's not populated? Decompile the callee(double-click the name to step into it) and go back to the caller
5. Check how many arguments the caller passes to the function by looking at the stack height
6. Remember that x64 MSVC passes 4 arguments in registers, so there are gonna be at least 4 arguments before stack is used if you're on x64
7. Remember that one entry in the stack is most often going to be a backup of rbp and shouldn't be an argument
8. Set the callee function's arguments to match your observations of the caller
9. Be happy (in most cases)

If you're dealing with indirect calls like call eax, tough luck buddy, read Igor Skochinsky's blog which doesn't feature an ADHD mode.
Well, first things first, let's find the call that causes this to happen. After you close the error popup, open the Output window and double-click the address next to the error message. This will bring you directly to the address where the culprit call happens:
Finding the culprit
Now, there are multiple options. If the function that is being called is an existing subroutine(not a register/offset), then you might've accidentally (or deliberately) decompiled the function, forcing IDA to analyze it and discover a bunch of arguments, bad stack or whatever else makes IDA unhappy. Review the function and see if that's the case. The easiest way out would be to remove the signature of the callee and try again. You can do that by clicking on the callee's name and pressing Y. In the "Set Type" window, erase everything and press Enter. Decompile again with F5 and see if it worked.
In this case, the function seems to demanding too many arguments off the stack - the caller doesn't provide enough and that shouldn't happen.
A better way to do this would be to analyze the function (if possible, of course) and find out how many arguments it actually uses. This is arch-dependent and cconv-dependent, in obfuscated/protected samples also closely tied to Post #3, but the general algorithm is as follows: 1. Decompile the callee once and go back (this is necessary for a basic function signature prototype). If that didn't magically fix the issue by itself, keep going: check the height of the stack at the position of the call. Do you not know how to? Or is it incorrect? It's time to consult Post #4!
 2. Determine the calling convention and, more specifically, how many registers are used. This sentence may not make a lot of sense to you, so generally it'll be as follows: no registers are used in x32 and 4 registers are used in x64. The latter is only true for the Microsoft Visual C++ compiler and is generally more complicated for Clang and GCC (research the System-V ABI). You can therefore deduct that, for example, when the stack height on a function call is 0x10 and you are on x64, the function accepts up to 6 arguments: 4 arguments were put in registers and the other 2 were put in the stack. That is without accounting for a backup of ebp - pure theory, more about that in the next step.
 3. For starters and on most regular occasions, you could calculate the amount of stack arguments by simply dividing the stack height by the architecture's pointer size(4 for x32 and 8 for x64, no exceptions here) and subtracting one. But remember: The stack height doesn't need to be specifically 0, 4 or 8 after the function call! Subtracting one stack entry is usually necessary because you're going to have a backup of ebp as the first thing on the function's stack, usually with the following prolog: push ebp; mov ebp, esp. Some functions, e.g. thunks, will not have it.
 4. Once you determine the amount of arguments, select the callee and press Y to change its signature. If you see negative stack heights (marked with a - in IDA view) after applying the new signature, you most likely placed too many arguments! Keep reducing the amount of arguments until you get it to work.
After fixing __noreturn, I calculated the amount of arguments to be 1 (8 / 4 - 1 = 1 - 4 is the pointer size here). I placed 1 argument of type void* and it worked! If you don't know an argument's type, void* is usually the go-to option.
In case the call you're having trouble with is a call to a register(call eax) or any other form of an indirect call, please refer to Igor Skochinsky's blog. This will require knowledge of runtime debugging! TODO for me: make a newbie-friendly page for this feature :) Remember that we're covering the basics here, there are many other cases where my guidance will not be enough.
Please don't attempt to tackle VMProtect with zero reverse engineering experience.