Holy cow, I wrote a book!
Occasionally, a customer will ask,
"What is Rundll32.exe and when should I use it instead of just
writing a standalone exe?"
The guidance is very simple:
Don't use rundll32.
Just write your standalone exe.
Rundll32 is a leftover from Windows 95,
and it has been deprecated since at least
Windows Vista because it violates a lot of modern
If you run something via Rundll32,
then you lose the ability to tailor the execution
environment to the thing you're running.
Instead, the environment is set up for whatever Rundll32 requests.
You get the idea.
Note also that Rundll32 assumes that the entry point you provide
corresponds to a task which pumps messages,
since it creates a window on your behalf and passes it as
the first parameter.
A common mistake is writing a Rundll32 entry point for a long-running
task that does not pump messages.
The result is an unresponsive window that
Digging deeper, one customer explained that they asked for guidance
making this choice because they want to create a scheduled task
that runs code inside a DLL,
and they wanted to decide whether to create a Rundll32 entry point
in their DLL,
or whether they should just create a custom executable whose sole
job is loading the DLL and calling the custom code.
By phrasing it as an either/or question,
they missed the third (correct) option:
Create your scheduled task with an
that specifies a CLSID your DLL implements.