I agree completely with your suggestions. However, I am not in a position
to implement such things. Also, there is no one place that the COM port
could be tied up. There are a number of different test programs that can
be running from variuos means. The simplest thing they could do would be
to unplug the USB cable and FORCE all processes to close handles to it.
Surely you know the names of the processes left alive in the previous
test pass (mytest1.exe or some such) - why not just kill all instances
of the process?
Personally I’d add a test step at the end that checked to make sure all
the test processes had been cleaned up. If they hadn’t I’d alert
someone so they could debug the test and fitgure out why it failed. But
I’m picky sometimes 
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@pdq.net
Sent: Thursday, April 14, 2005 8:44 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Enumerating processes with open handles to a device
Uh, well…actually…shutting down the process which has the COM port
locked IS the entire scope of this excercise. We have some internal
test automation tools that ned to connect to an external device via a
virtual COM port. Sometimes this port is locked for some reason by some
process left over from a previous testing session or something. The
testers are semi-computer types. I was asked to see if I could find the
COM ports on the system (relatively easy and already done) and then if
the COM port is in use, show the process that has it locked and
optionally stop it all from within an application.
I have considered just spawning off either the “Handles” program or the
SI process explorer application and give the user instructions on how to
determine which process and then kill it.
This is not all that major of a feature. It’s something they wanted as
a “really nice to have” feature to ease the workload on the testers. I
was hoping there was a simple “ObEnumDeviceObjects” and then
“ObShowHandlesForObject” calls to get me this information. It sounds
like it may be a LOT more involved than that.
Thanks,
Greg
>
>
>
>
>
> Can’t really help on the “explain how Process Explorer works” other
> than the fact that the Sysinternals people know a WHOLE LOT more than
> the average MS kernel developer. OSR may also be able to help a bit
> on their side, but I doubt that they will just say "Greg’s a very nice
> chap, let’s give him some source code"… So if you’re willing to pay
> for the consultation, I guess that either Sysinternals or OSR would be
> able to supply you with some source code that solves this problem.
>
> But I’ll ask some other questions, just in case it helps in some way,
> either in giving ME some more clues to work on, but more importantly
> someone else may have some ideas.
>
> So what exactly is the problem you’re trying to solve? I presume
> shutting down the process that uses the COM-port isn’t really the goal
> of the WHOLE excercise…
>
> Is there any reason you can’t just download the Process Explorer and
> use that to find the correct process? [My guess is that you want to do
> this automatically].
>
> Also, what is the scope? Are you planning to use this for some
> broad-spread thing, or just internally within a group in a particular
> company, or what?
>
> –
> Mats
>
>
> xxxxx@lists.osr.com wrote on 04/14/2005 04:20:52 PM:
>
>> You have it absolutely correct about filter drivers (at least that is
>> the same as my understanding). My problem is that I have to be able
>> to do this on a system without that filter driver installed from the
>> beginning.
>
>> I have to be able to run this program on any machine at any time and
>> find out what process has the serial port in use so I can shut it
>> down.
>>
>> I know…strange problem…Not my preferred way of handling things,
>> but this is what I am stuck with.
>>
>> Thanks,
>> Greg
>> >
>> >
>> > But system internals doesn’t use normally published ways of getting
>> > to things that is displays.
>> >
>> > Have I missed something about filter drivers (I haven’t actually
> written
>> > one, but I have read a bit about them here on the NTDev list), but
>> > shouldn’t the filter driver load at the same time (just after) the
> actual
>> > driver, and be installed before anything else is done to the
driver?
> How
>> > else can a filter driver be sure to filter everything that goes to
>> > the “real” driver? Or is the serial driver one of the special case
>> drivers?
>> >
>> > –
>> > Mats
>> >
>> > xxxxx@lists.osr.com wrote on 04/14/2005 03:32:40 PM:
>> >
>> >> That would be a good way to go about it. Unfortunately, I may not
>> >> be abl;e to install a filter driver before the other process
starts.
>> The
>> >> System Interals program can somehow do this withuot having a
>> >> filter
>> > driver
>> >> installed.
>> >>
>> >> Thanks for the suggestion.
>> >>
>> >> Greg
>> >>
>> >> >
>> >> > I’m pretty sure that this is NOT something that the OS supports
>> >> > (officially at least). Sysinternals Process Explorer is a good
>> >> > example of a well-written tool that does things “not quite
>> >> > according to the
> book”.
>> >> >
>> >> > One idea that comes to mind is to register which process as it
>> opens
>> > the
>> >> > com-port. This could be done by a filter driver that passes
>> >> > through
>> >> all
>> >> > IRP’s except the “Open” and “Close” ones Obviously, at the
>> >> > point
>> of
>> >> > “open”
>> >> > you will have to add the “current process” to the list of
>> >> > processes
>> > that
>> >> > have this current device open, and in “close” you remove the
list.
>> I
>> >> > believe the Open and Close IRP’s are treated synchronously in
>> >> > the
>> > context
>> >> > of the process that performs the call, rather than being queued
>> >> > up
> and
>> >> > performed in some other context.
>> >> >
>> >> > –
>> >> > Mats
>> >> >
>> >> > xxxxx@lists.osr.com wrote on 04/14/2005 02:57:11
PM:
>> >> >
>> >> >> OK, I know this must be simple and I’m overlooking it. I have
>> >> >> a
> need
>> > to
>> >> >> determine what process (if any) has a serial port open. Sounds
>> > simple,
>> >> > huh?
>> >> >> Afterall, OSR and System Internals both have free downloadable
>> > utilities
>> >> >> that can be used to back into this, but nowhere can I find any
>> >> source.
>> >> >>
>> >> >> If anyone knows of source snippets I could start with and then
> build
>> > the
>> >> >> functionality I need, or could just offer pointers to where to
> even
>> >> > begin,
>> >> >> I’d great appreciate it. I have scoured the MSDN library,
>> >> >> OSR’s material and SystemInternal’s material.
>> >> >>
>> >> >> I tried starting with the Object Manager’s APIs, but nothing
>> jumped
>> > out
>> >> > at
>> >> >> me there. I think I have looked at just about ever Kernel-mode
>> API
>> > that
>> >> > is
>> >> >> documented and still nothing obvious. It’s got to be something
>> > simple.
>> >> >>
>> >> >> Thanks,
>> >> >> Greg
>> >> >>
>> >> >
>> >> >
>> >> > —
>> >> > Questions? First check the Kernel Driver FAQ at
>> >> > http://www.osronline.com/article.cfm?id=256
>> >> >
>> >> > You are currently subscribed to ntdev as: xxxxx@pdq.net To
>> >> > unsubscribe send a blank email to
> xxxxx@lists.osr.com
>> >> >
>> >>
>> >>
>> >>
>> >> —
>> >> Questions? First check the Kernel Driver FAQ at http://www.
>> >> osronline.com/article.cfm?id=256
>> >>
>> >> You are currently subscribed to ntdev as:
>> >> xxxxx@3dlabs.com To unsubscribe send a blank email to
>> >> xxxxx@lists.osr.com
>> >
>> >> ForwardSourceID:NT00010B5E
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as: xxxxx@pdq.net To
>> > unsubscribe send a blank email to xxxxx@lists.osr.com
>> >
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at http://www.
>> osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>> ForwardSourceID:NT00010B76
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@pdq.net To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
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
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com