|
Dave Kreskowiak wrote: From your description, the only recovery would be to cold boot the computer.
I've rebooted several times with no effect. The green light comes on during power-up, but that's it; the drive still doesn't work..
|
|
|
|
|
I opened up the computer, uplugged the DVD drive, took it out, and then put it back in. It's working now.
|
|
|
|
|
I've spent more than a week on a problem with getting the serial number string descriptor from a USB device that uses USBSER as driver.
The USBSER driver doesn't seem to support any kind of functionality for getting the serial number directly and in some cases the device is a composite device which adds to the problem.
So I've tried another way...
I get the symbolic link for my device either through WM_DEVICECHANGE or by enumeration with the Setup API. I enumerate the USB device tree and get hold of the parent hub on which my device is connected and then ask the hub for the string descriptor.
So far so good, but...
There are two scenarios where I'm afraid this may fail:
1. If a hub with multiple devices attached is inserted, the order of device notifications may not be in "port" order although it seems that way
2. When enumerating devices at application start the enumeration order may not be in "port" order
When I iterate through the ports of the parent hub and I find a new device I assume it is the one I got the notification for, but this method fails under the circumstances mentioned above.
Mapping the original symbolic link for my device to a specific port number in the parent hub would solve my problem.
I think I have found a solution for this, but I cannot find any information that verifies this as a reliable method even though I've google'ed like insane.
I use SetupDiGetDeviceRegistryProperty() and get the "address". The address seems to correspond to the port number of the parent hub.
I've tried this on my machine (XP SP3) and it works all right, even if I move things around, add hubs in between and so on.
Can anyone verify this as reliable or unreliable, or point me toward some Microsoft-ish information about using SDRP_ADDRESS on USB devices?
Is it an undocumented feature or pure coincidence?
Thanks
--
Rog
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Jan Axelson has written books and articles on this stuff. http://www.lvr.com/[^] Hope the link helps.
modified 1-Aug-19 21:02pm.
|
|
|
|
|
Thanks Richard,
it's a good link but unfortunately this was the first resource I tried to find information in.
Moreover I have in front of me Jan's all editions of "USB Complete" plus the "Serial Port Complete".
Her books are very good, as well as her site, but I haven't found anything that clearly states "calling SetupDiGetDeviceRegistryProperty with SDRP_ADDRESS gets the hub port number the device is connected to"... 
I was hoping that someone would have found a similar statement from Microsoft, or someone who has successfully used a similar technique.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Howdy:
I'm new to the driver scene and I need a small pointer or insight to a situation I'm encountering. The Vista (Server 2K8) SDK has a plethora of power management calls, making power management trivial. Unfortunately, we still support Windows 2K, so we cannot rely on these calls. After a bit of registry and internet trolling I found which registry entries need to be modified in order to allow a device to bring the computer out of a sleep state. My question is: how do I ensure that the changes are applied to the hardware, rather than just being a new entry in the registry? It occurs to me that reboot would do the trick, but that seems a little drastic to me. Is there a less disruptive way of telling Windows that a device's PnP (where the power settings are stored) settings have changed? Maybe I don't need to?
cheers,
-B
|
|
|
|
|
OK, you dont need to make any registry changes directly, you do it through device manager.
Change the view to 'view by connection' and then, on the power management tab of any device (usb hubs for example) check the two power options. Power saving and wake computer (if possible. If one is greyed then that functionality is not enabled on that device controler).
Secondly, the driver itself for the device attatched ot that controler has to be capable of sending a wait wake. To do this it examines the device characteristics data to see if the device is capable of sleeping, what the relevant device sleep state is for a respective syystem sleep state and if both that device state is wakable and if that system state is wakable.
If you get all that lot right then you system will wake when the device gets an external input.
Morality is indistinguishable from social proscription
|
|
|
|
|
Sorry, I should have made myself clearer. This is to be done programmatically. We would like to determine if a network interface can wake a machine. Also, we would like to give our user's the option to turn this on for any network adapter they may be using to route our application's traffic.
Regards,
-B
"[F]reedom isn't a licence, it's responsibility." [David Gerrold, Author's Note in "The Man Who Folded Himself", 2003, p. 119]
modified on Monday, September 15, 2008 10:48 AM
|
|
|
|
|
Take a look at the setupdi functions. They are how you can query device informaitonm from usermode.
Morality is indistinguishable from social proscription
|
|
|
|
|
I actually have an implementation that uses those functions; unfortunately, they are not all necessarily supported on Windows 2000: it depends on how up-to-date the machine is. Sorry, I'm just making this really difficult  (It's not intentional, however; it just our current predicament.)
Regards,
-B
"[F]reedom isn't a licence, it's responsibility." [David Gerrold, Author's Note in "The Man Who Folded Himself", 2003, p. 119]
|
|
|
|
|
If SP4 gives you those functions then surely you can mandate it?
Morality is indistinguishable from social proscription
|
|
|
|
|
We may just have to; I was just hoping that we could cover everyone, including those who do not want to touch any of their perfectly-ok-and-running-machines. If I had any say in it, I'd make XP the base requirements, period; unfortunately, we have far too many people with production Windows 2000 machines for this to be feasible.
Thank you for your help. I'll need to further contemplate how backwards compatible we care to--or can--be.
Regards,
-B
"[F]reedom isn't a licence, it's responsibility." [David Gerrold, Author's Note in "The Man Who Folded Himself", 2003, p. 119]
|
|
|
|
|
I know what you mean. I've still got an NT4 box for testing one of the apps I'm responsible for.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
My condolences 
I believe we dropped that flavour of Windows just before I joined the team. A lot of the core kernel calls was there, but some of the niceties are only just being address now.
Regards,
-B
"[F]reedom isn't a licence, it's responsibility." [David Gerrold, Author's Note in "The Man Who Folded Himself", 2003, p. 119]
|
|
|
|
|
I'm doing C# work, not drivers so it's not as bad, but there've been more than a few places where I've been burned by win32 changes. Two that I recall are the behavior of a listbox if you click in the empty area below the last item, and that NT4 doesn't correctly display 32bit color depth icons. The customer this software is for has never moved past 2k to XP (claimed not to be able to turn off some XP services that tried doing auto updates when on isolated networks). We think, but aren't sure that all the NT4 boxes are finally gone, and that the next rev of the software (whenever that is) can be 2k only.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
dan neely wrote: I'm doing C# work, not drivers
Thats worse. The kernel never changes that much, 95% of todays kernel api on Windows 7 is just the same as NT4 (its probably the same as NT 3 but I didnt start writing drivers till NT4). The only new bit is PnP and power stuff, and in fact an NT4 driver can still run on Vista etc. They are also all written in C.
By comparison, having new apis / languages thrust on you every time the latest catchword technology hits the streets, COM, Java, .Net etc, many of which end up dying after 5 or 10 years wasting all the effort one invested as a career move.
Give me the kernel anyday.
Morality is indistinguishable from social proscription
|
|
|
|
|
Anyone not using a tried and tested service pack for an OS is a dick anyway so just tell them feature 'X' isnt available unless they do.
Morality is indistinguishable from social proscription
|
|
|
|
|
I'm pretty sure they wouldn't take to kindly to that
Like I mentioned before, if I had my druthers, they'd all be forced to use XP SP3, no exception. Unfortunately, the reality is that this will not happen, and there is no reason for them to update the old machines, in their minds, since none of the boxes face the outside world. It will slowly happen, however, as they retire old hardware: so I'll just bide my time.
Regards,
-B
"[F]reedom isn't a licence, it's responsibility." [David Gerrold, Author's Note in "The Man Who Folded Himself", 2003, p. 119]
|
|
|
|
|
Hi All,
Today I just re-installed my Graphics Driver with the latest WHQL Driver release (175) for nVidia 8800 GT under Windows XP. I had installed beta version of their new driver which comes with CUDA 2.0. The performance was much lower when I installed the beta one. That was the reason I switched back to my older version of driver.
but during the installation the screen went blank 2-3 times and finally, it had shown "No signal". I tried with restoring old restore points and boot the machine with last known good configuration. but I never could install the driver for that.
Finally I formatted Windows XP and tried installing it fresh. but again it has been failed. The same problem occurs. In the same machine I've an installation of Windows Vista, which is working fine with the hardware.
When I checked the device manager i found that the driver for PCI Device is missing. But aint sure whether we need to install these things or not. However its not get going. Can you help me in this regard?
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
I just replaced my monitor with another one. then it was working fine. I think it's the problem with monitor driver. It seems to be corrupted somehow and loading the resolution and refreshing rate which the monitor can't handle.
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
Have you tried connecting both the working and non working monitors at the same time? You should be able to control the system using the former and change the latter to a generic monitor driver and set it to run at a resolution/refresh rate it will function at.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
I've got a WD My Book Premium ES 500GB external hard disk (and most likely will never be buying anything from Western Digital in the future). I should have read Amazon customer reviews before I bought it, oh well...
It started dying after 11 months (or so) with Acronis TrueImage complaining that it could not read from some sectors. Now I have it off for most of the time as it's constantly spinning after powered up and slows down Windows, even hangs up Explorer (I think this should not happen, Vista should cope with a non-accessible external hard drive where there's nothing OS related, right?!  ).
Anyway, I suspect this may be only a corrupt NTFS, because it's generally accessible after some time. I looked at it in GParted and it just told me to run chkdsk /f. Fine, but this particular drive has a feature which puts it in a stand by mode when it's idle for 10mins or more. So, I run CHKDSK and it happily proceeds to fix some errors with MFT and Virtual Map (whatever this is..), but after some time I notice it's not 'moving' (CHKDSK, that is) and the drive is in stand by mode - at this point I can no longer access its contents w/o restarting it. :/
Do you have any ideas on how to prevent it from going to sleep?
|
|
|
|
|
Assuming the warranty is void (or you value your data more than the remainder of it), pop it out of the enclosure and connect it as an internal HD to your PC.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
dan neely wrote: Assuming the warranty is void
I think I have 1 more year to go.  I'm trying to solve the problem myself without support first and without tinkering with hardware, but thanks.
|
|
|
|
|
Pawel Krakowiak wrote: I think I have 1 more year to go.
that makes it more interesting, your warranty coverage will most likely result in your getting a new package and loosing whatever data was on the drive itself. The only possible exception would be if they did a diagnosis first and IDed a problem with the enclosure itself.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
