Btw, "update.bat" does reboot with the help of "shutdown.exe", which has default timeout in 20 seconds. So you could just sit and wait for a reboot instead of closing PowerShell. Do you think that it would be clearer to users to see the line explaining about reboot scheduled within 20 seconds?
Also that span of timeout can be set through the parameter.
Version with added check of relevance of controller and hub inf-files before actual installation.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
@echo off
date /T > .\update.log.txt
set controller=".\Controller-Driver_as-first"
set hub=".\Hub-Driver_as-second"
set switch=".\Switch-Driver_as-third-if-applicable"
set step=checking Controller driver folder...
echo %step%
echo %step% >> .\update.log.txt
dir %controller% /B >> .\update.log.txt
if %errorlevel% NEQ 0 exit
set step=checking Hub driver folder...
echo %step%
echo %step% >> .\update.log.txt
dir %hub% /B >> .\update.log.txt
if %errorlevel% NEQ 0 exit
set step=checking Switch driver folder...
echo %step%
echo %step% >> .\update.log.txt
dir %switch% /B >> .\update.log.txt
if %errorlevel% NEQ 0 exit
set step=checking Controller driver inf-file...
echo %step%
echo %step% >> .\update.log.txt
deviceChecker64.exe %controller%\iusb3xhc.inf >> .\update.log.txt
if %errorlevel% NEQ 0 exit
set step=checking Hub driver inf-file...
echo %step%
echo %step% >> .\update.log.txt
deviceChecker64.exe %hub%\iusb3hub.inf >> .\update.log.txt
if %errorlevel% NEQ 0 exit
set step=updating Controller driver...
echo %step%
echo %step% >> .\update.log.txt
dpinst.exe /path %controller% /sa /q /f /c >> .\update.log.txt
echo result code: %Errorlevel% >> .\update.log.txt
set step=updating Hub driver...
echo %step%
echo %step% >> .\update.log.txt
dpinst.exe /path %hub% /sa /q /sh /c >> .\update.log.txt
echo result code: %Errorlevel% >> .\update.log.txt
set step=updating Switch driver...
echo %step%
echo %step% >> .\update.log.txt
dpinst.exe /path %switch% /sa /q /sh /c >> .\update.log.txt
echo result code: %Errorlevel% >> .\update.log.txt
set step=rebooting Windows (in 20 seconds)...
echo %step%
echo %step% >> .\update.log.txt
shutdown -r -f -c "Rebooting after Intel USB3/3.1 drivers update"
echo result code: %Errorlevel% >> .\update.log.txt
@mbk1969 :
Thanks for your updated script and the idea to check the on-board USB 3.0 devices regarding their compatibility before starting the real driver installation.
Unfortunately it didn’t work with my Intel 170 chipset system, which is definitively compatible with the mod+signed Intel USB 3.0 drivers.
Here is the slightly customized code of the file named update.bat, which I have used with the mod+signed 64bit Intel USB 3.0 driverpack:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
@echo off
date /T > .\update-log.txt
set controller=".\Controller-Driver_as-first"
set hub=".\Hub-Driver_as-second"
set switch=".\Switch-Driver_as-third-if-applicable"
set step=checking Controller driver folder...
echo %step%
echo %step% >> .\update-log.txt
dir %controller% /B >> .\update-log.txt
if %errorlevel% NEQ 0 exit
set step=checking Hub driver folder...
echo %step%
echo %step% >> .\update-log.txt
dir %hub% /B >> .\update-log.txt
if %errorlevel% NEQ 0 exit
set step=checking Switch driver folder...
echo %step%
echo %step% >> .\update-log.txt
dir %switch% /B >> .\update-log.txt
if %errorlevel% NEQ 0 exit
set step=checking Controller driver inf-file...
echo %step%
echo %step% >> .\update-log.txt
deviceChecker64.exe %controller%\iusb3xhc.inf >> .\update-log.txt
if %errorlevel% NEQ 0 exit
set step=checking Hub driver inf-file...
echo %step%
echo %step% >> .\update-log.txt
deviceChecker64.exe %hub%\iusb3hub.inf >> .\update-log.txt
if %errorlevel% NEQ 0 exit
set step=updating Controller driver...
echo %step%
echo %step% >> .\update-log.txt
DPInst64.exe /path %controller% /sa /q /f /c >> .\update-log.txt
echo result code: %Errorlevel% >> .\update-log.txt
set step=updating Hub driver...
echo %step%
echo %step% >> .\update-log.txt
DPInst64.exe /path %hub% /sa /q /sh /c >> .\update-log.txt
echo result code: %Errorlevel% >> .\update-log.txt
set step=updating Switch driver...
echo %step%
echo %step% >> .\update-log.txt
DPInst64.exe /path %switch% /sa /q /sh /c >> .\update-log.txt
echo result code: %Errorlevel% >> .\update-log.txt
set step=rebooting Windows (in 20 seconds)...
echo %step%
echo %step% >> .\update-log.txt
shutdown -r -f -c "Rebooting after Intel USB3/3.1 drivers update"
echo result code: %Errorlevel% >> .\update-log.txt
Hallo,
Fernando begged me to say something about this issues. I didn’t read the whole thread. I just saw that you are trying to build a cmd script.
I prefere to do this task in an other way: Modding DPinst.exe itself.
This can be done using an additional XML file called "DPInst.xml"
The content of this file should look like this:
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
<?xml version="1.0" ?>
<dpinst>
<search>
<subDirectory>Controller Driver</subDirectory>
<subDirectory>Hub Driver</subDirectory>
<subDirectory>Switch Driver</subDirectory>
</search>
<forceIfDriverIsNotBetter/>
<suppressAddRemovePrograms/>
</dpinst>
The folder should then look like this:
1
2
3
4
5
2
3
4
5
.\Controller Driver\<< driver files >>
.\Hub Driver\<< driver files >>
.\Switch Driver\<< driver files >>
.\DPInst.xml
.\DPInst.exe
This will trigger dpinst.exe to look into the given sub folders and install the drivers if, and only if there is a suitable device. Otherwise the driver will just be copied into corresponding windows folders without getting used. There are lots of other (unnecessary) switches - you can even mod the window appearance of dpinst. You might search the web by your own.
Greetings Zwulf
@Zwulf :
Thank you very much for your contribution and advice.
Questions:
1. Will your modified DPInst files work with drivers, which have been modified and signed by me?
2. What happens, when only the on-board Intel USB 3.0 Controller is supported by the related driver, but not the other Intel USB 3.0 device(s)?
3. Is it possible, that the related DPInst.exe file checks before starting the update, whether all attached drivers match the HardwareIDs of the related on-board USB 3.0 devices? If yes, how?
1.) yes if the certificate has been installed bevor
2.) Like i said: Dpinst will only install suitable drivers
3.) I’m not sure why somthing like this is necessary. If only controller and hub fits, dpinst won’t install the switch driver. There is a installAllOrNone switch. But this way most of the time you won’t install anything. I haven’t read anything about a real test mode so far. But of cause you are free to read the manual by your own.
Have a Nice Evening
Problem with using dpinst.xml is you can`t select different modes for different folders in group. Mode is either forced or not forced for whole group. So it is more flexible to use command line parameters.
Fernando, new app - substitute for dpinst.exe - is almost ready. So we will test new scripts soon.
You may be right, Zwulf’s method may be problematic with Mobile systems, which have unsupported Intel USB 3.0 Hub devices.
Nevertheless I was curious about how Zwulf’s method will work with my Z170 system running a freshly installed Win10 x64.
This is what I did after having created the DPinst.xml file and the driver folder as recommended by Zwulf:
- As first step I imported the Win-RAID CA Certificate.
- Then I did a right click onto the DPInst64.exe and simply executed it as Admin (no CMD or PowerShell required!).
- Immediately the install process was intiated by showing a GUI, where I was asked, if I want to install these drivers. I clicked "Yes".
- Now the driver update process started. After round about 1 minute I got automaticly access again to my keyboard and mouse, which were still connected to the Intel USB 3.0 ports.
At the same time I got this result:
- I clicked onto the "Finish" button and rebooted.
- After having rebooted I checked the in-use driver of all 3 USB 3.0 devices.
These were the results:
My conclusion:
- Zwulf's method works for me and is absolutely easy to use.
- For "normal" desktop systems with an on-board Intel USB 3.0 Controller it seems to be very safe.
- There is no need to move the input devices to any non-Intel USB ports.
@Zwulf :
Thank you very much for your xml code and the description of the procedure!
Receiving such results means that it is not a mandatory - to update Controller drivers with force option (i.e. have disk option in Device manager), right?
The installation has been forced by Zwulf’s code of the XML file.
Will this work also with Intel and Asmedia USB 3.0/3.1-drivers on a Win10x64 with Z97-K ?
Will it give us more transfer-speed ? We have now about 120MB/sec , this means 20GB copy to external HDD in about 4 minutes.
If we have clear answer on these two questions , we will certainly try !
I did not look at his text of xml-file. I was hardwired to forced installation for controller and not-forced - for hub, so I did not offer this to try.
Ok, so we can abandon script file then?
Why should it not work?
You should test it yourself. If you are not satisfied with the speed of the Intel driver, you can reinstall the generic MS ones.
But ASMedia bundle has its own installation app, right?
I mean this thread has nothing to do with non Intel USB devices.
Yes indeed Asmedia has its own USB 3-drivers , but Intel is also involved in USB 3 !
We need more test results before we can decide this. Maybe we will need your script for problematic (Mobile) systems.
@all:
For those, I want to test Zwulf’s method, I have attached an already prepared driverpack, which will be usable with Win8.1 x64 and Win10 x64.
It contains my mod+signed 64bit Intel USB 3.0 drivers v5.0.1.38 with Zwulf’s DPInst.xml file.
The driver installation can be done by simply doing a right click onto the DPInst64.exe and choosing the option "Run as Administrator".
Good luck!
64bit Intel USB 3.0 Test Drivers v5.0.1.38 mod+signed.rar (2.32 MB)
May be worth to post in main USB thread?
You are right.
Tomorrow I will add my report (with the steps I have done) and the link to the 32/64bit driverpacks to the main USB drivers thread.
http://forums.guru3d.com/showthread.php?t=412349
Still useful tool. You can offer it to guys in confusion/trouble to receive report on devices for troubleshooting times.
Also it can help in your experiments with devices and drivers.
@mbk1969 :
Thanks for the link to the DevCon tool, which seems to be very interesting.
I will test it as soon as possible.