Dear Robert
Robert Newton wrote:
>Hello
>
>I developped a driver for a 1394 device for fast isoch transfer. Now I
>discovered a thing which I don’t like but I don’t know if it’s normal:
>
>To test I have:
> - A Laptop, Win2k, SP1 with a built in 1394 connector
> - A desktop PC, WinXP, SP1 with a 1394-PCI card
>
>During development I have to do lot’s of driver updates (obviously every
>time I want to verify the new compiled source code), so I would
>appreciate if this takes a very short time. Now if I update the driver
>on the laptop I don’t have to restart it after completing the
>installation process. But on the desktop PC a message box pops up after
>every update, telling me the changes will not take effect before I
>restart the PC. Why is this difference? Is it not possible with a
>1394-PCI card to load a WDM driver without restarting the PC?
>(I’m doing all updating in the device manager)
>It’s not a fatal problem, it’s just time eating and annoying to restart
>the PC all the time.
I don’t know any reason why you can’t update without reboot on a
desktop machine - I do it all the time. However, if your device is
plugged in or if you still have a process running with a handle to a
once valid device the system will not unload your driver. Since it
can’t unload the driver it can not update so will force the reboot.
OK, good point, I think indeed this might be the problem. Just to be
sure: DriverEntry is called each time I connect the first of my 1394
device. And the driver will be unloaded not before I disconnected my
last 1394 device, is that correct?
If yes, I have that “unload” problem, but I don’t know why. It even
happens if I didn’t access the device from an application.
By the way, you can generally get by with just copying the driver over
top of the original and skipping the update driver step. However it is
a good thing to be running something like dbgview and adding debug
messages so that you can see the driver being unloaded and reloaded.
If the old driver is not unloaded the new one will not take effect.
I’m doing that. I’m the proud owner of a SoftICE kernel mode debugger
and like using this “instrument”! How can I see where the unloading
procedure actually stuck? I’m not using an own driver unload routine.
What is the PNP call sequence for unplugging a 1394-er device? (I guess
surprise removal).
thanks and regards
Daniel
>So, I assume that the problem in allocating isochronous resources with
>the newer SP’s of win2k and WinXP is propably the same (I also get a
>STATUS_NOT_SUPPORTED). At least I saw that in the diag sample in
>t1394_IsochAllocateResources() also a kernel mode IRP is created. I will
>test this immediately now!
Yes, I mean’t to mention that Win2000 >= sp2 is the same as WinXP in
this regard.
>The unfair thing is that I didn’t find any description of that
>requirement of a “kernel mode IRP” in the DDK description. From where
>should one know that?
>OK I know it now and I’m happy with it!
Good question. I had the same problem. The Microsoft support guys gave
me the answer. It took them about 5s to figure out what the problem
was so I’m guessing that I wasn’t the first one to ask them.
>kernel mode IRP (I didn’t know before that there are two kind of
>IRP’s…) as it is provided on the 1394diag example in the WinXP DDK it
>worked perfectly! I think this is rather strange, what sense does it
>make NOT to serve a user mode IRP only a kernel mode IRP? For what is
>this difference user mode - kernel mode IRP anyway?
Others on this list can probably give a good answer to this. The
Microsoft support guy I talked to indicated that it was some sort of
security/system robustness issue.
Robert Newton