, AndyC wrote

The point is this happens as part of a default Scheduled Task, not how the shell handles it if you click an invalid shortcut.

In that case, just remove the scheduled task that does this. It's in "C:\Windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1".

It's not about security. If IsBadXXXPtr fails, the pointer is invalid. If it suceeds, the pointer might still be invalid. So basically making any decision on it is entirely pointless.

On the contrary. If you define a method SetCallbackFunction(void* foo), you probably don't want to create a difficult to debug error where somebody gives you a bad code pointer and then later your program crashes. If instead you call IsBadCodePtr(foo) on the argument, you'll see the bad argument as it comes into your function instead of having to make guesses at who called SetCallbackFunction last.

Checking something global exists/is valid then following up by attempting to do something based on the assumption that it is valid is fundamentally flawed on a multitasking OS. The only valid way to do it is to perform the action and respond correctly to a failure, but obviously that's not an option here and as such there is no correct way to write this functionality and it shouldn't exist at all.

lock(object){   if(object.IsValid)   {      object.DoSomething();   }} 

Is entirely valid despite running on a multitasking OS - and is even valid if there is network traffic involved so long as the lock is a lock that is honoured by the client and the server. A case in point is SQL - because of transactions you are able to make a decision based on data in the SQL database and then update something else all atomically, despite the fact that there's a "race-condition" and network traffic involved