Why does this script BSOD-ize windows ?

[Rikki Cattermole via Digitalmars-d-learn]

On 21/07/2015 10:36 p.m., Baz wrote:
> On Tuesday, 21 July 2015 at 10:28:27 UTC, Rikki Cattermole wrote:
>> On 21/07/2015 10:14 p.m., Baz wrote:
>>> ---
>>> import std.process;
>>> import core.thread;
>>> import std.random;
>>>
>>> void main(string[] args)
>>> {
>>>      string on = "netsh interface set interface \"Connexion au réseau
>>> local\" Enable";
>>>      string off = "netsh interface set interface \"Connexion au réseau
>>> local\" Disable";
>>>
>>>      while(true)
>>>      {
>>>          executeShell(on);
>>>          Thread.sleep(dur!("msecs")(uniform(2000, 5000)));
>>>          executeShell(off);
>>>          Thread.sleep(dur!("msecs")(2000));
>>>      }
>>> }
>>> ---
>>>
>>> It's stable if i remove the random time after connecting, otherwise in
>>> the current shape it crashes Windows. Don't know why. Any idea ?
>>>
>>> Note that you can test by replacing the name of my interface by yours
>>> ('Connexion au réseau local').
>>
>> This shouldn't be a D bug, it's reasonable D code.
>> Can you give us the BSOD text?
>> Also OS version + platform would be nice.
>>
>> I've asked a friend who knows Windows better then anybody should and
>> basically relaying this to him FYI.
>
> - Window 7 64 bit (up to date) but the program is running in 32 bit,
> compiled with latest DMD 2.067.1.
> - involved hardware is onboard REALTEK on Gigabyte H97-HD3, driver up to
> date.
>
> I have not the BSOD error code because I ran this script while away.

I'll summarize what my friend is saying.

netsh is potentially going away. Don't use it if you can.
Since you are using a localized system it, it may be causing issues for 
the interface name.
Internally to Windows, it does not use the interface names. It uses id's.

Oh and most importantly use Windows API not netsh.

You should instead be using ConvertInterfaceAliasToLuid[0] to get the UID.
There does not appear to be a c-function to disable/enable an interface. 
Supposedly[1] could be used to enable/disable the card which provides 
it. Although I would recommend against it.

Lastly, this is half good news and half bad news. We have found a way[2] 
through WMI/COM to enable/disable them. Although I've never gone the 
path of COM let alone WMI which could be a rather mess to deal with in 
D. May be easier to use PowerShell for this.

Either way, my current theory revolves around Windows kernel + 
subsystems not liking it toggling so frequently. Friend is a little more 
conservative on it.

[0] 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365821(v=vs.85).aspx
[1] 
https://msdn.microsoft.com/en-us/library/windows/hardware/ff552169(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/library/hh968170(v=vs.85).aspx