View Single Post
  #37  
Old June 26th 14, 08:21 PM posted to alt.windows7.general
Al Drake
external usenet poster
 
Posts: 793
Default I have no "Batteries" in device manager.

On 6/26/2014 8:11 AM, Charles Lindbergh wrote:
On Wed, 25 Jun 2014 20:16:17 -0400, Al Drake wrote:

On 6/25/2014 6:20 PM, Paul wrote:
Al Drake wrote:
On 6/25/2014 11:51 AM, Paul wrote:
Charles Lindbergh wrote:
On Wed, 25 Jun 2014 10:48:31 -0400, Paul wrote:

Charles Lindbergh wrote:
On Wed, 25 Jun 2014 03:32:34 -0400, Al Drake
wrote:

On 6/24/2014 8:06 PM, Charles Lindbergh wrote:
On Tue, 24 Jun 2014 19:37:13 -0400, Al Drake
wrote:

On 6/24/2014 5:06 PM, Paul wrote:
Al Drake wrote:
I have been trying to install an APC UPS RS 1000 on one of my
newly
built systems but I keep getting a USB device error. For some
reason
this piece of hardware is not recognized and the software
will not
install. This USB failure is only happening with this UPS. I am
sure
all my USB ports are operational as I've tried them all. I am
using
some for USB keyboard and Bluetooth device and have swapped
them all
to make sure that wasn't the problem. After searching endlessly
for a
fix I noticed the missing "batteries" access in the device
manager. I
have also searched endlessly for a fix for this problem but all
I come
up with is posts regarding missing battery icon on laptops. I
installed Windows 7 a few days ago clean which went well or so I
thought. The last thing I wanted to do is set up the UPS and
I'm all
set. I have one on all my systems and never had a problem of
this
nature ever. I tried different UPS but I get the same USB error
with
them all.

My last hope was that someone here has knowledge of this
issue and
knows what to do.

Thanks for any help.

Al.
The site requires registration, to get a copy of the software.

http://www.apc.com/resource/include/...ase_sku=BR1000



I would look for a USB driver folder, and see whether there is
any
intention for the USB port to be a serial device (like an RS232
port).
In which case, the interface class is defined in Windows already.

If it had a totally custom interface, there might be VID and PID
matching in the INF, that hints at the custom nature.

The manual will tell you to either install the Powerchute
*before*
plugging in the UPS for the first time. Or, it'll tell you
the UPS gets plugged in *after* Powerchute is installed.
The order dependence, exists for cases where a Windows generic
driver "hijacks" the device and prevents normal installation.

Since I can't look at the product software, that's about
all I can offer. I'm sure the clowns at APCC will be only
to happy to walk you through this.

Technical Support You own an APC product
800-555-2725
and you need technical assistance

If the unit was in front of me, I'd dig out a copy of
UVCView or USBView from Microsoft, and also check to
see if the device is registering or not (and the Config
information is visible).

HTH,
Paul
Thanks Paul.

To begin with I have the manual as I registered some years ago
when I
got my first APC UPS. I have 6 all working fine. Nothing is
mentioned
about this particular problem. I tried installing the SW first
but it
halts when it does not detect the USB handshaking. I tried
attaching the
UPS first but the USB error persists. Your first sentence is
confusing
to me as I have no idea what to look for by name and where to
look.
Would that be the System folder perhaps? I tried removing the
unknown
USB device and allowing a search of the Windows folder, the
Windows
installations disk and a HDD removed from another system that had
the
UPS working but I continually get the message the driver
installed is
correct or something to that affect.

I was concentrating on learning more about the lack of batteries
indications in the device manager as I have connected this
particular
UPS without the software on other computers and let windows take
control
but not in this case obviously.

I have hesitated contacting APC tech support as I know it's
not a
faulty device as I have indicated it works on other systems.

So I can only conclude there is something missing on the one OS
install.

Yes? No?

Do you have legacy USB support (or some such description) enabled
in the UEFI /
BIOS?

I would thoroughly examine the UEFI / BIOS USB settings maybe play
with them a
bit.

Can you post a link to the documentation for your new motherboard?

I looked over BIOS and everything looked propper as all USB posts
are operational just not liking the UPS.

http://www.gigabyte.com/products/pro...px?pid=3960#ov

This is the board I'm working with.
1. I tried to look this over, but the online documentation is
somewhat peculiar.
I see the USB ports have an ALWAYS ON power feature for charging
gadgets such as
cell phones. I wonder if this could be causing a conflict with the
UPS? Is
there a way to turn this off in the bios?

2. I was also wondering, if you download a Linux distro, such as
Mint and run it
from a USB stick or DVD, it would be interesting to know if the
Linux OS sees
the UPS. If not, then the problem probably is not with your Windows
installation.

3. You indicated you have UPS on your other machines, have you tried
a different
UPS on this machine?

4. I vaguely remember that APC would use special USB cables. Are
you using the
cable that came with the UPS?

5. Have you looked at the USB section of your device manager? Does
it show an
unrecognized device?
Regarding (1):

USB is a host to peripheral protocol. The host delivers +5VSB on VBUS,
to power peripherals which do not have their own power source. This
is sufficient for many items with modest power requirements (including
some 2.5" disk drives). It's part of the USB spec, to expect the
host to make power available on the VBUS wire. The UPS will not be
thrown off by this. And power is not supposed to flow in the other
direction - an exception to that, is self-powered USB hubs, which
lack the necessary relay to cut power flow when it would be possible
for it to flow in the wrong direction. Simple diodes are not enough
(too much drop). If your computer starts behaving weirdly after
a self-powered hub is plugged in, it could be current flowing up
the cable via VBUS (when it's not supposed to).

Charging features for phones require a couple things. Sufficient power
from the +5VSB on the ATX supply (check the label on the side, and
assume the motherboard uses at least 1 ampere while sleeping). The D+
and
D- pins may have an encoding, done with strap resistors or otherwise,
which signals to the charging peripheral, the characteristics of the
power source. Without the encoding on D+/D-, some charging devices
may refuse to charge at all.

For (5), UVCView, USBView or the USBTreeView should show some
kind of entry when the UPS is plugged in. Even if no driver is
present, the config space of the USB device should be listed,
as well as information about whether endpoints formed or not
as a result of the connection. The information is not in a
human-friendly format, but any info is better than none at all.

Sites like this one, can help with the decoding chore.

http://www.beyondlogic.org/usbnutshell/usb5.shtml

Paul

You are right, he should not try disabling the USB feature I
referenced. Every
engineer I was trained with always designed and built perfect systems
which
comply perfectly with standards and theory.

And let's face it, changing a single switch in the bios requires a
lot of
effort. :-)

Charles, I try to concentrate on "likely" things. USB power
wouldn't be high on my list to check. And the "Always On" feature
is more likely to be an encoding on D+/D-, as bus power may be
present there in any case. Bus power should be there, to support
"wake" events, such as keyboard or mouse waking of the computer.

If the motherboard "nominates" some ports for goofy features (by
sporting a different color plastic for the connector tab), you can
always choose another port. Powder blue is for USB3, so that's not
a scary one. If a USB port had red plastic, perhaps that would
imply a special property. And if you're superstitious, you could
always try another port. One of the black colored USB2 ones.

Right now, I would be interested in UVCView, USBView, or USBTreeView,
to differentiate between a hardware or a software problem. If
absolutely nothing shows up, then it's some kind of hardware problem.
If you have a USB powered LED lamp, that can be used as a way
to see if bus power is available or not (in case a fuse opened).
You would plug the LED into one of the two USB ports in a "stack",
as a means of monitoring fuse state. While USB overcurrent should
also pop up on the screen, if the fuse opens, having a visual
indicator helps.

"1.1 or
110" on USB ports are arranged in "stacks of
two",
top to save a few pennies on extra fuses and
caps

+5VSB ---- polyfuse ---+---- Upper_USB_Port VBUS (500ma max
USB2 --)
|
+---- Lower_USB_Port VBUS (500ma max
USB2 --)
| ^
Active_low, OC# overcurrent --+ +--- Monitor a port with a USB LED
lamp,
or any device with power LEDs
on it

HTH,
Paul

Here you go Paul.

=========================== USB Port2 ===========================

Connection Status : Device failed enumeration
Port Chain : 1-2

======================== USB Device ========================

+++++++++++++++++ Device Information ++++++++++++++++++
Device Description : Unknown Device
Device ID : USB\VID_0000&PID_0000\5&339E9CE1&0&2
Driver KeyName : {36fc9e60-c465-11cf-8056-444553540000}\0017
(GUID_DEVCLASS_USB)
Driver Inf : C:\Windows\INF\usb.inf
Legacy BusType : PNPBus
Class : USB
Service :
Enumerator : USB
Location Info : Port_#0002.Hub_#0001
Manufacturer Info : (Standard USB Host Controller)
Capabilities : Removable, RawDeviceOK
Address : 2
Problem Code : 43 (CM_PROB_FAILED_POST_START)
Power State : D3 (supported: D0, D2, D3, wake from D0,
wake from D2)

---------------- Connection Information ---------------
Connection Index : 0x02
Connection Status : 0x02 (DeviceFailedEnumeration)
Current Config Value : 0x00
Device Address : 0x00
Is Hub : 0x00 (no)
Number Of Open Pipes : 0x00 (0)
Device Bus Speed : 0x00 (Low-Speed)

------------------ Device Descriptor ------------------
bLength : 0x00 (0 bytes)

The suggestion here, is to look in setupapi.log for more info.
Which would certainly be the thing I'd recommend on WinXP,
less sure it would contain useful info on Windows 7. There
are several files similar to that in C:\Windows\inf.

http://janaxelson.com/forum/index.ph...c=736.5%3bwap2

I looked up this number.

36fc9e60-c465-11cf-8056-444553540000

http://pcsupport.about.com/od/driver...class-guid.htm

USB 36FC9E60-C465-11CF-8056-444553540000 USB host controllers
and hubs

And that could be a reference to the thing on the host side, rather than
the peripheral itself. Since the device config space info is not available,
it probably means the motherboard hub didn't succeed in communicating
with the thing. The only thing weird about this report, is the
CM_PROB_FAILED_POST_START with the word "POST" in it. It implies
it did get half-way through the startup process, but then
disappeared. By half-way through, I'm referring to being
recognized as a HID input device, rather than the setup
being fully function. There are probably two steps, and it
failed half way through the first step.

*******

I looked up the APC UPS types, and got a match here.

http://www.microsoft-questions.com/m...-with-ups.aspx


HID\VID_051D&PID_0001.DeviceDesc="APC Battery BackUP"
HID\VID_051D&PID_0002.DeviceDesc="APC Battery BackUP"
HID\VID_051D&PID_0003.DeviceDesc="APC Battery BackUP"

Those are the kinds of VID/PID that the hardware enumeration
would find (if it got further along than your error indicates).
And hidbatt.sys is supposed to pick up from there. So first
it is detected as a HID device (human interface device
like a mouse or keyboard, or other slow speed input), and then
somehow the OS decides it is handled by hidbatt.sys . There
would likely be two driver files in the driver stack for it.

In Windows 7 C:\Windows\inf, the file input.inf contains this:

HID\VID_051D&PID_0001.DeviceDesc="APC Battery BackUP"
HID\VID_051D&PID_0002.DeviceDesc="APC Battery BackUP"
HID\VID_051D&PID_0003.DeviceDesc="APC Battery BackUP"

I'm guessing, that once the OS discovers new hardware,
gets the particular VID/PID, it finds a match on input.inf.
And some info there, causes hidbatt.sys to be used.

In battery.inf, I can find a reference to hidbatt and
also to APC. There could be different drivers, depending
on the UPS manufacturer, as listed in battery.inf.

APC.DeviceDesc = "APC UPS"

So that's what it looks like it is supposed to do. First
be discovered as input.inf HID device, then (somehow)
be discovered as battery.inf material.

*******

Would Linux find it ? Maybe. At this point, I'd be willing
to give that a shot. Run "dmesg" from a Terminal, and
see if the APC is detected or not.

Paul


Ok, so then if Linux finds the device how will that help when I switch
back to Windows? I'm not getting this................?



Now that you told us there is an unrecognized device in Windows 7, the Linux
test would be moot. Previously, I was under the impression the device was not
being detected at all.

Actually you are more accurate and my assessment was wrong. I was
going by the pop-up that appeared when I plugged it the device.
It reads "One of the USB devices attached to this computer has
malfunctioned and Windows does not recognize it.
Recommendation
Try reconnecting the device. If Windows still does not recognize it,
replace the device."

I think we can safely say this report is also inaccurate.


Ads