Windows 8 usb not found

[klowe016]

Hello,

I've been trying endlessly to get my IPhone to be recognized on Windows8. Only twice has autoplay started or has it showed as found in ITunes. Generally, it get the "usb not found" message or nothing at all happens.

Any technical suggestions?

Thanks

 

[The_Prophecy]

Tried plugging it into a different USB port, and then also on a different computer? Does it work in either of those cases?

 

[gomerpile]

Uninstall all drivers itunes, remove unknowing device in device manager, reboot, Install what you did before in compatibility mode. Reboot, plug in your Iphone should work now

 

[The_Prophecy]

You can't run drivers in compatibility mode (for that matter, you can't even run drivers, at least in the same way you run an executable program). Drivers have no compatibility mode... they either load and work in a given OS, or they don't, and you need to look for newer ones.

@ klowe,

Also check to make sure your version of iTunes is up to date. If you installed an old version of iTunes (and by extension, and older driver version) and are using a newer Apple device, the included driver may not support the device you are connecting, or may simply not work properly under Windows 8. In either case, can you verify what version of iTunes you installed on that computer?

 

[gomerpile]

no Itunes can be run in compatibilty which has drivers for iphone and pod, Any exe or most driver packed in .exe can be run in compatibily, anything inside that .exe will be installed using that setting. This is how we setup drivers nowadays, been like that since win98. Last time I remember manually unpacking drivers was for win 95. Or win 98 usb.

Example are my saitek driver exe was setup in compatibilty

Drivers for my saitek usb

I tunes, also you can choose to download Iphone drivers and install the same way without setting up iphone, i guess this is why i have no problems with 8 i know how to set it up

How to install drivers in compatiblity mode for anyone not knowing


COMPATIBILITY HARDWARE DEVICE DRIVERS:

1. Right Click the driver installation file and select Properties/Compatibility Tab. Select the appropriate options in from the list in the following image.

2. Click Apply/OK.

3. Right Click the file and select the Run As Administrator option to install.

 

[The_Prophecy]

This is just the installer application. This does not affect the driver itself. I was already aware that you could run the installer this way, but what I am referring to is the driver itself once it has been extracted from the installer and loaded when the device in question is connected.

The one time running the installer the way you showed above will have an effect, is when the installer does a version check on the copy of Windows it is running under. If the installer application has a specific list of Windows build numbers it looks for to determine whether the installer will let the user run the program, running the installer in question in compatibility mode will change the build number of Windows that gets reported to match one on the allowed list.

For example:

Say an Nvidia driver works under all current versions of Windows (lets use XP up to Windows 8 for the sake of argument). The installer when first run does a version check to determine the Windows build number. If it is being run under Windows XP, the installer will have "5.1.2600" reported back to it. It then goes and checks to see whether "5.1.2600" is an acceptable build number. When it sees that it is, the installer loads the initial UI and allows the install to continue.

Now lets say this driver has been completely updated to work perfectly within Windows 8, but some developer at Nvidia forgot to add "6.2.9200" to the list of acceptable build numbers before they released the new driver. In every instance, you could run the installer on your Windows 8 computer, and it would fail, saying that your operating system version is not supported (even though as mentioned earlier, it works perfectly). At this point, you could run the installer under compatibility mode to report the build number as "6.1.7600", and it would work perfectly.

Now on the flip side, if no Windows 8 compatibility was in place in this fictional driver, but a developer mistakenly added "6.2.9200" to the acceptable builds list, the installer would run like nothing was wrong. Once the driver was installed though, with no Windows 8 compatibility in place, the driver would bluescreen the new OS (or cause any number of other issues). Re-running the installer in compatibility mode would have absolutely no effect, as the environment the driver was being loaded into would be exactly the same (still Windows 8).

 

[gomerpile]

You are wrong. http://support.microsoft.com/kb/927524
http://social.technet.microsoft.com/Forums/en-US/w7itprohardware/thread/80cae5ee-dc98-4a2f-8284-a1ab826059b7/

I should know this I have packed .exe with a packer being a linux user you know how important that is, packing windows and linux is almost the same. All that is done is its using compatibility mode for locations. the way you are thinking is a readme file in the download of drivers that explains where to place the files. This files dont need compatibility becase you know where to place them. That is all compatibility mode does is file locations registry locations. But is is very important with drivers if the device has no idea where to find them.

Now adays the pack is using install of drivers using the properties of the exe application: Reason for this is to make sure the files are place in its proper folder, and registry>if this is not done the drivers may fail do to inproper install of locations,, this is why, most likely reason his device is unknown

Like I said this is why I do not get the problems that others do, I know most of the time what is going on before the install even happens.

 

[The_Prophecy]

You are wrong. http://support.microsoft.com/kb/927524
http://social.technet.microsoft.com/Forums/en-US/w7itprohardware/thread/80cae5ee-dc98-4a2f-8284-a1ab826059b7/

I should know this I have packed .exe with a packer being a linux user you know how important that is, packing windows and linux is almost the same. All that is done is its using compatibility mode for locations. the way you are thinking is a readme file in the download of drivers that explains where to place the files. This files dont need compatibility becase you know where to place them. That is all compatibility mode does is file locations registry locations. But is is very important with drivers if the device has no idea where to find them.

Now adays the pack is using install of drivers using the properties of the exe application: Reason for this is to make sure the files are place in its proper folder, and registry>if this is not done the drivers may fail do to inproper install of locations,, this is why, most likely reason his device is unknown

Like I said this is why I do not get the problems that others do, I know most of the time what is going on before the install even happens.

All these refer to is the installer itself. The bottom part of your first link refers to a manual driver install, but this can only be done after the inf file is extracted from it's original container. Are you saying the Compatibility Mode attributes are retained when the files are extracted from the installer exe, thus allowing the system to know where to place them in the event of a manual install? AFAIK, that's not the case, so a manual install in compatibility mode according to your first link is not possible.

For file placement, special shell objects were set up for application installers to use which automatically re-direct the installer to the new (correct) location for the version of Windows in question as seen below. I've highlighted a couple.

For 32 vs. 64 bit issues (I'm referring to the Program Files / Program Files (x86) folders here), Compatibility mode doesn't account for that.

Edit: 32 vs 64 bit issues are not accounted for at least as far as the Compatibility Mode UI is concerned.

 

[gomerpile]

All these refer to is the installer itself. The bottom part of your first link refers to a manual driver install, but this can only be done after the inf file is extracted from it's original container. Are you saying the Compatibility Mode attributes are retained when the files are extracted from the installer exe, thus allowing the system to know where to place them in the event of a manual install? AFAIK, that's not the case, so a manual install in compatibility mode according to your first link is not possible.

For file placement, special shell objects were set up for application installers to use which automatically re-direct the installer to the new (correct) location for the version of Windows in question as seen below. I've highlighted a couple.

http://i.imgur.com/ShUHDCG.png

For 32 vs. 64 bit issues (I'm referring to the Program Files / Program Files (x86) folders here), Compatibility mode doesn't account for that.

Edit: 32 vs 64 bit issues are not accounted for at least as far as the Compatibility Mode UI is concerned.

what we are TELLING YOU is how to install driver in compatatibility mode, this is how we express the install of drivers, you can argue all you want but we wil still continue to tell people to install the drivers in compatibility mode. Even when the evidence is staring in your face and have other techs showing you how we express the install of drivers in compatibility mode, you still refuse to admit your wrong. THIS IS HOW WE EXPRESS THE INSATLL OF DRIVERS USE COMPATIBILITY MODE. When you use compatibilty mode during install the files are extracted using the codes of an older processor or whatever else contents is registred during in the install. The EXE for drivers to include the change of codes during install. This is all written in the EXE pack. when the check box is clicked and ran, the scripts within that alter the files to include the compatible code for that system you have checked. providing it is ran In admin, if this is not check, the files will not be updated to include the codes a prompt will ask you to allow admin rights( . Same as any compatible mode for anything. Webbrowers the same thing. I can include the code in my script content in my webpage to include compatibilty mode and when you click on compatible in your webbrowers it call on the language and that script to change, the script i have written contanis the info of browers. THIS IS THE SAME THING IN A EXE FILE. YOU CAN ARGUE ALL YOU WANT BUT I KNOW.

 

[The_Prophecy]

gomer... the ultimate question(s) I am getting at here is this:

What changes does Compatibility mode make when installing a driver? Is it simply changing the version number reported to the application when the installer is run? Or are there deeper changes being made?

I'm not arguing the fact that one can run a driver installer in Compatibility Mode. That's obvious. What I am trying to argue here (correctly or incorrectly as the case may be) is that doing so has no tangible effect on the way the driver itself runs or behaves after it gets installed. Does a driver installed via compatibility mode behave thereafter as though it is in a previous version of Windows?

My thinking here goes like this:

Installer for Driver X gets run in Compatibility Mode for Windows 7, while running under Windows 8. Compatibility mode provides sufficient support to get the driver installed as though the environment is indeed Windows 7. Once the computer is rebooted, does the driver upon being loaded by the OS still believe it is running under Windows 7? Or does it now see that it is actually Windows 8?

 

[gomerpile]

gomer... the ultimate question(s) I am getting at here is this:
This instructions are written when compatible mode is choosen then executed, providing admin is used a , the way cpu, chipsets, and directories talk to each other. every os has different instructions, compatible mode changes this in driver files . I'm not an expert with the codes but I have had to go and find instructions for drivers to include into a script file loaded from a text file, all packed in the EXE
What

changes does Compatibility

mode make when installing a driver? Is it simply changing the version number reported to the application when the installer is run? Or are there deeper changes being made?codes for older OS mostly CPU codes that talk to the OS and drivers. There are different instruction written for versions of OS. .

I'm not arguing the fact that one can run a driver installer in Compatibility Mode. That's obvious. What I am trying to argue here (correctly or incorrectly as the case may be) is that doing so has no tangible effect on the way the driver itself runs or behaves after it gets installed. Does a driver installed via compatibility mode behave thereafter as though it is in a previous version of Windows?

My thinking here goes like this:

Installer for Driver X gets run in Compatibility Mode for Windows 7, while running under Windows 8. Compatibility mode provides sufficient support to get the driver installed as though the environment is indeed Windows 7. Once the computer is rebooted, does the driver upon being loaded by the OS still believe it is running under Windows 7? Or does it now see that it is actually Windows 8?

 

[The_Prophecy]

So this does actually make a tangible change to the driver in order to not just install it, but keep it operating as stable as possible under the older OS after the install is complete?

 

[gomerpile]

So this does actually make a tangible change to the driver in order to not just install it, but keep it operating as stable as possible under the older OS after the install is complete?

+1 whatever he said