Builtin DOS in XP SP2

NTDEV
1

I’ve got a whole bunch of legacy MIDI drivers (the dll kind) that provide
MIDI over alternate transports, talk to PLCs, do GUIs and just a whole bunch
of other oddball things that are appropriate around a theatre.

It turns out that as of SP2 for XP, virtually every builtin NT function or
program opens all of the MIDI drivers when it starts up, and interrogates
all of the MIDI ports on each driver. This wouldn’t be too horrible, except
for one thing. This happens some 8-10 times after boot and before the logon
message is displayed. It happens some 6 or so times before NT even
considers network startup.

If these programs simply loaded the MIDI drivers this might not be horrible
(although it is, obviously). But since they also interrogate all the MIDI
ports, any driver providing transport over the network *must bind to the
network* to respond to these queries.

Well, as a ‘feature’ of SP2, the ‘bind’ function doesn’t time out if the
network isn’t loaded. Nor does it return an error. As a result, boot never
finishes, since all of the network initialization programs open the MIDI
ports before starting the network, and all end up hanging forever in bind.
Which leaves the system in a bind, as it were.

After discovering this lovely little feature, we were able to spend a day or
so of hacking, and finally discovered that if we interrogate the running
usercode before attempting the bind, and looking for about 5 hard-coded
usercodes, that usually we could get the system to boot correctly, by simply
refusing to open and claiming there were no MIDI ports on the drivers.
Isn’t this a lovely ‘fix’ for the problem? It will probably last until SP3,
when they will probably change the strings of some of the usercodes used
during boot. In case anyone is wondering, yes, I consider this a hack and
not a fix. However, it is the ONLY thing I found that seems to work.

Sigh, but it turns out that it isn’t a complete hack. I found out from a
user today that ipconfig opens the MIDI ports too, seemingly after locking
the network in some way or other. So we are up and running, and running as
a user so my hack checks don’t work, and now the user can lock up the system
(and network, I think) again simply by typing ipconfig at the run prompt.

Can anyone think of a way I can hack around this lovely little situation?
It would be ideal if bind simply timed out or returned an error as it
should, but it doesn’t.

And anyone having the temerity to suggest I convert these legacy dlls to KS
drivers will be shot! I once spent an ugly 4 months fighting to get a
dirt-simple MIID-over-serial root-enumerated KS driver working, and I still
have nightmares about it. I don’t even want to consider the possibility of
doing this with something that has to talk to the network, or open a window
and display graphics, or execute a user program. I can do any of those
things in about 2 hours from a dead start using the old dll format. Since
none of those things represent a PnP enumerated hardware device, they fall
FAR outside the range of what KS was ever “designed” to accomplish. It
makes the hacks I’ve had to go through to keep from locking up SP2 systems
look like mil-spec life support system designs.

Help greatly appreciated, as long as it doesn’t include the letters KS.

Thanks,
Loren

2

Just curious (a shot in the dark), what component is opening the midi
ports? What does the callstack look like on one of these spurious
opens?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: Friday, May 27, 2005 10:16 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Builtin DOS in XP SP2

I’ve got a whole bunch of legacy MIDI drivers (the dll kind) that
provide
MIDI over alternate transports, talk to PLCs, do GUIs and just a whole
bunch
of other oddball things that are appropriate around a theatre.

It turns out that as of SP2 for XP, virtually every builtin NT function
or
program opens all of the MIDI drivers when it starts up, and
interrogates
all of the MIDI ports on each driver. This wouldn’t be too horrible,
except
for one thing. This happens some 8-10 times after boot and before the
logon
message is displayed. It happens some 6 or so times before NT even
considers network startup.

If these programs simply loaded the MIDI drivers this might not be
horrible
(although it is, obviously). But since they also interrogate all the
MIDI
ports, any driver providing transport over the network *must bind to the
network* to respond to these queries.

Well, as a ‘feature’ of SP2, the ‘bind’ function doesn’t time out if the
network isn’t loaded. Nor does it return an error. As a result, boot
never
finishes, since all of the network initialization programs open the MIDI
ports before starting the network, and all end up hanging forever in
bind.
Which leaves the system in a bind, as it were.

After discovering this lovely little feature, we were able to spend a
day or
so of hacking, and finally discovered that if we interrogate the running
usercode before attempting the bind, and looking for about 5 hard-coded
usercodes, that usually we could get the system to boot correctly, by
simply
refusing to open and claiming there were no MIDI ports on the drivers.
Isn’t this a lovely ‘fix’ for the problem? It will probably last until
SP3,
when they will probably change the strings of some of the usercodes used
during boot. In case anyone is wondering, yes, I consider this a hack
and
not a fix. However, it is the ONLY thing I found that seems to work.

Sigh, but it turns out that it isn’t a complete hack. I found out from
a
user today that ipconfig opens the MIDI ports too, seemingly after
locking
the network in some way or other. So we are up and running, and running
as
a user so my hack checks don’t work, and now the user can lock up the
system
(and network, I think) again simply by typing ipconfig at the run
prompt.

Can anyone think of a way I can hack around this lovely little
situation?
It would be ideal if bind simply timed out or returned an error as it
should, but it doesn’t.

And anyone having the temerity to suggest I convert these legacy dlls to
KS
drivers will be shot! I once spent an ugly 4 months fighting to get a
dirt-simple MIID-over-serial root-enumerated KS driver working, and I
still
have nightmares about it. I don’t even want to consider the possibility
of
doing this with something that has to talk to the network, or open a
window
and display graphics, or execute a user program. I can do any of those
things in about 2 hours from a dead start using the old dll format.
Since
none of those things represent a PnP enumerated hardware device, they
fall
FAR outside the range of what KS was ever “designed” to accomplish. It
makes the hacks I’ve had to go through to keep from locking up SP2
systems
look like mil-spec life support system designs.

Help greatly appreciated, as long as it doesn’t include the letters KS.

Thanks,
Loren

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

> Just curious (a shot in the dark), what component is opening the midi

ports? What does the callstack look like on one of these spurious
opens?

I never bothered getting callstacks. I had KD up and was watching debug
messages coming out of my dll. This was some months back that I first had
to deal with this, and from the comments I have left in the code, I know it
is called from usercodes SYSTEM, LOCAL SERVICE, and NETWORK SERVICE. We had
to defer any network activity until we found both explorer.exe appears and
logonui.exe disappears, or we have a guaranteed hang.

Once the system is up and running, it appears that almost all programs will
load the MIDI dlls, so I suppose it must be a function in a common library.

I’ll see if I can figure out some clever debugging info I can crank out to
dump the program name and call stack without having to breakpoint the open
and do it manually a few hundred times.

Looks like I’m already spitting out the process name and the user name every
time we get called. Only thing I don’t have is the callstack, but maybe dll
load messages will give me a hint. I’ll try to set something up later and
see if I can get some potentially usable info.

Loren

4

You might try this in windbg:

bu !function “k;g”

this will show the callstack and then continue automatically. If you
.logopen before setting the bp, you don’t even have to watch the output,
just view the log later. If you need the user mode symbols, you might
need “.reload;k;g”, but that will makes things real REAL slow (unless
all symbols are local) b/c it will force a reload of symbols each time.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: Saturday, May 28, 2005 12:17 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Builtin DOS in XP SP2

> Just curious (a shot in the dark), what component is opening the midi
> ports? What does the callstack look like on one of these spurious
> opens?

I never bothered getting callstacks. I had KD up and was watching debug
messages coming out of my dll. This was some months back that I first
had
to deal with this, and from the comments I have left in the code, I know
it
is called from usercodes SYSTEM, LOCAL SERVICE, and NETWORK SERVICE. We
had
to defer any network activity until we found both explorer.exe appears
and
logonui.exe disappears, or we have a guaranteed hang.

Once the system is up and running, it appears that almost all programs
will
load the MIDI dlls, so I suppose it must be a function in a common
library.

I’ll see if I can figure out some clever debugging info I can crank out
to
dump the program name and call stack without having to breakpoint the
open
and do it manually a few hundred times.

Looks like I’m already spitting out the process name and the user name
every
time we get called. Only thing I don’t have is the callstack, but maybe
dll
load messages will give me a hint. I’ll try to set something up later
and
see if I can get some potentially usable info.

Loren

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

I believe that every time you start a program, multimedia subsystem is loaded.
You know, to play all that rings and bells. Can it be multimedia subsystem
who loads all of MIDI drivers on initialization?

I’ve got a whole bunch of legacy MIDI drivers (the dll kind) that
provide MIDI over alternate transports, talk to PLCs, do GUIs and just
a whole bunch of other oddball things that are appropriate around a
theatre.

It turns out that as of SP2 for XP, virtually every builtin NT
function or program opens all of the MIDI drivers when it starts up,
and interrogates all of the MIDI ports on each driver. This wouldn’t
be too horrible, except for one thing. This happens some 8-10 times
after boot and before the logon message is displayed. It happens some
6 or so times before NT even considers network startup.

If these programs simply loaded the MIDI drivers this might not be
horrible (although it is, obviously). But since they also interrogate
all the MIDI ports, any driver providing transport over the network
*must bind to the network* to respond to these queries.

Well, as a ‘feature’ of SP2, the ‘bind’ function doesn’t time out if
the network isn’t loaded. Nor does it return an error. As a result,
boot never finishes, since all of the network initialization programs
open the MIDI ports before starting the network, and all end up
hanging forever in bind. Which leaves the system in a bind, as it
were.

After discovering this lovely little feature, we were able to spend a
day or
so of hacking, and finally discovered that if we interrogate the
running
usercode before attempting the bind, and looking for about 5
hard-coded
usercodes, that usually we could get the system to boot correctly, by
simply
refusing to open and claiming there were no MIDI ports on the drivers.
Isn’t this a lovely ‘fix’ for the problem? It will probably last
until SP3,
when they will probably change the strings of some of the usercodes
used
during boot. In case anyone is wondering, yes, I consider this a hack
and
not a fix. However, it is the ONLY thing I found that seems to work.
Sigh, but it turns out that it isn’t a complete hack. I found out
from a user today that ipconfig opens the MIDI ports too, seemingly
after locking the network in some way or other. So we are up and
running, and running as a user so my hack checks don’t work, and now
the user can lock up the system (and network, I think) again simply by
typing ipconfig at the run prompt.

Can anyone think of a way I can hack around this lovely little
situation? It would be ideal if bind simply timed out or returned an
error as it should, but it doesn’t.

And anyone having the temerity to suggest I convert these legacy dlls
to KS drivers will be shot! I once spent an ugly 4 months fighting to
get a dirt-simple MIID-over-serial root-enumerated KS driver working,
and I still have nightmares about it. I don’t even want to consider
the possibility of doing this with something that has to talk to the
network, or open a window and display graphics, or execute a user
program. I can do any of those things in about 2 hours from a dead
start using the old dll format. Since none of those things represent
a PnP enumerated hardware device, they fall FAR outside the range of
what KS was ever “designed” to accomplish. It makes the hacks I’ve
had to go through to keep from locking up SP2 systems look like
mil-spec life support system designs.

Help greatly appreciated, as long as it doesn’t include the letters
KS.

Thanks,
Loren