, evildictaitor wrote

*snip*

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

I don't think users should be expected to hack about inside OS defined scripts to get decent behaviour.

*snip*

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.

Except you don't know if it's valid or invalid. The most IsBadXXXPtr can possibly tell you is that it was valid/invalid at some arbitrary point in the past. So absolutely any code which ever uses foo still has to call it defensively and handle the situation in which it was a bad pointer. Thus making the IsBadXXXPtr call entirely redundant.

*snip*

1
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.

If you can hold a lock on something, then it's no longer entirely out of your control, so that's fine (just as a similar pattern on entirely private objects is). Getting a lock on something that doesn't exist (or at best whose existance is indeterminate) doesn't work though and hence we find ourselves back at the IsBadXXXPtr anti-pattern.