MadBoy

discountpc: correct behaviour when 'none' is used is clean devicepath on start of the function but it is supposed to add 'more' paths as it finds .inf's later on. If it doesn't add anything and you are sure path's are correct and inf's are there then there might be error in code Have you DOWNLOADED newest version that i uploaded? Maybe it was cached or so? As Netman66 gave me debug output that helped to solve the problem of paths not getting added to registry on English (probably other versions too, except Polish) windows. Maybe it was same cause for you too? As for the Windows Wizard it's complicated issue. Are you sure you have correct 'paths' added in registry (as i said earlier there might have been problem with earlier version 0.5.4 and all before that)? I'll release 0.5.5 shortly to fix the confusion ;p

Once again i have reuploaded 0.5.4 version. Now it should FIX the issue with registry path not being added correctly. Please test it. And those who downloaded earlier 0.5.4 version pls redownload it.

I have reuploaded the version again. Try it now Should be no error of that kind. Here's yours: [23:58:06] - DEBUG in REGISTRYDEVICEPATH FUNCTION 0: Directory of C:\Asus [23:58:06] - DEBUG in REGISTRYDEVICEPATH FUNCTION 1: Directory of C:\Asus To say the truth that lines says it all. Here's min: [16:15:10] - DEBUG in REGISTRYDEVICEPATH FUNCTION 0: Katalog: C:\All_Drivers [16:15:10] - DEBUG in REGISTRYDEVICEPATH FUNCTION 1: Katalog: C:\All_Drivers and i use ": " as splitting behaviour to get what i need. guess i need to find other way. Seems each language version has diffrent 'DIR' behaviour lemme work on it. actually you don't need to test more. I have to think of better way to solve it. TNX!

Netman66: i have uploaded new binary (same version) so just redownload it and use Debug=yes in config file. It should give big output That might give me some hints on what can be wrong.

I guess you have french version of windows. I'll try to add some more debug lines to .inf search function and we will see. Lets say it will be added in new version ;P

TAiN: well if you set the program in Automatic mode GUI should pop_up and work automagically, all you need to do is to close the app after it's done. I can make it close automatically too but problem is that when program is closed it 'applies' default settings to registry. That way when you close it too soon and the plug & play devices are still searching for drivers they might end up in bad situation. If someone has idea what my program can look for while the Plug & play devices are installed (some process or something) and when Windows finishes it, as for now i have NO CLUE how to make it work so my program CAN realy tell you when P&P is done. If someone knows what my program can look for i will gladly hear it Netman: you are right with the removal process. As discountpc spotted it should be 01 not 1 and i overlooked it when changing things. Fixed in 0.5.4 that will be out soon. Also can you verify if that C:\A has .inf file in it ? or somewhere in dir in dir. You must be aware that drivers can't be in packed form for example just setup.exe or so. Lemme know? Discountpc: try playing with registry_path and report if it fixes your issues. Changelog for 0.5.4 - one little typo when coding new functionalities, which caused removal process of devices with problem ID 01 to be not removed (tnx discountpc) Get it :/

New version is out: Changelog for 0.5.2-0.5.3 - removed commandlines (useless) - cleaned up some more useless code - added new ADVANCED option called problem_ids in hardware.ini. - added new ADVANCED option called registry_path in hardware.ini. Possible settings for hardware.ini for [ADVANCED] Keep in mind those options are only good if you know what you are doing. Application will work JUST FINE without those settings being in hardware.ini. It will use defaults then. AGAIN. Do NOT use those options if you are unsure what they do. Registry_path - possible options are Begin, End, None. This option controls if "%SystemRoot%\inf;" is supposed to be added in the begining, end or none at all in the registry line HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion :: DevicePath. I believe if you set it to End it will first look for correct driver for your device in YOUR NEW DRIVERS and then in the default Windows drivers dir. If you set it to None then drivers from default Windows drivers dir won't be taken in consideration at all. Keep in mind that some crucial devices like USB that are supported by WINDOWS use this dir. Problem_Ids - here you put numbers separated by commas i.e. 1,10,18,28,37,39. This means that devices that match one of those problems IDS will be removed. You can either increase the numbers or decrease if you think default i use is too much. On that page: http://support.microsoft.com/kb/310123/en-us you can find what each problem means. Hardware.ini for newest version 0.5.3 but with ADVANCED options in use looks like this: [INFO] Start=Manual Mode=Standard Drivers_drive=REMOVABLE Drivers_dir=\All_Drivers Device_manager=On Method=RegistryDevicePath Logging_to_file=Yes Logging_option=Advanced Drivers_Packed=No Copy_drivers=No Copy_where=C:\Drivers Delete_drivers=No Create_backup=No Leave_registry_entries=No Debug=No [ADVANCED] Registry_path=Begin Problem_Ids=1,10,18,28,37,39 Check it out and lemme know how it works discountpc i hope you are satisfied with those 2 options Should work for you!

Well i can't realy see why you would have that problem. But lets see. Drivers_drive=C Drivers_dir=\All_Drivers Put some drivers in that or other dir specified by you. When you put them there (can be dir in dir in dir etc) check if .inf files exist (as the tool checks for dirs with inf's and add them to registry. If it can't find those inf's then it does nothing to you device path's. I'll upload 0.5.3 in a sec and update first page. Check these option (make sure to read what they mean). Then monitor what happens in registry to your key while you set 'None' in that option. If the key changes. Then it means registry access is okey and it prolly can't find drivers or so. That option works only with 0.5.3+ [ADVANCED] Registry_path=None

Well my programs shows all devices that have some problems. Only some of those problems are driver related. My program only removes devices that match: 1, 18, 28, 37, 39 problems. You can find what they mean here: http://support.microsoft.com/kb/310123/en-us Your code: Code 10 If the device has a FailReasonString value in its hardware key, that string appears as the error message. The driver or enumerator puts this registry string value there. If there is no FailReasonString in the hardware key, you receive the following error message: This device cannot start. (Code 10) Recommended resolution Device failed to start. Click Update Driver to update the drivers for this device. On the General Properties tab of the device, click Troubleshoot to start the Troubleshooting Wizard. " I'm not sure if this code should be added to my program. Can you tell me what happens if you delete device from DeviceManager and rescan p&p? DOes it work correctly? Finds drivers and all? If yes then i can add code 10 to my program. I could probably even add line in .ini where you could specify which codes are removed and which aren't but it might be risky for some ppl As for the old drivers being used instead of the new supported it's because in registry path you have old_path for drivers ("%SystemRoot%\inf;") and the new paths are added after that. So the searching starts in Windows dir first then it goes to wherever your drivers are. I wonder if we will do little swap places so the "%SystemRoot%\inf;" would be added to end, and new drivers paths to begining. We can make some test like that. Eventually we could also have an option to completly not use "%SystemRoot%\inf;" in the registry path (and only have program set it back to defaults on exit, as it is doing it now). That way Windows will be forced to look for new drivers instead using old ones. Only disadvantage i can see now is that some devices that are nativly supported by Windows (like usb devices) might not be detected correctly while the program is working. Okey i'll try to prepare some new version with what i just said And gimme shouts about the Code 10 and other codes if you think they should be added. Or maybe that .ini option will be better??

urie: He means that when he connects any device Windows asks him with it's WIZARD to point the drivers for device. Avneet: Check registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ Find there key: DevicePath Type of the key: REG_EXPAND_SZ Value of the key must have at least this: %SystemRoot%\inf; It can also have other paths after semi-colon. Check it, Hope it helps.

This method is completly diffrent method. Sata/Scsi drivers HAVE to be included in Windows installation as otherwise your hdd's will be invisible for Windows so you won't be able to install it. This method is good for other drivers such as graphic cards, audio cards etc Cheers,

Sure, it will be done when ppl will say it WORKS I mean there seems to be a problem with packed drivers for some users until i am told ALL is WORKING there's no sense to add help file

I have uploaded new version 0.5.0 on first page. DOwnload it from there and lemme know if the Unpacking works now. I redownloaded commandline version from page changed things a bit. Please check and give feedback. Use Debug = Yes in config file for debugging

Devilrunner: If $method = "SetupCopyOemInf" Then _AddLineBox("Integrating drivers with SetupCopyOemInf method.") $DirOutput = Run(@ComSpec & " /c DIR /A:D /S " & $path_to_drivers, '', @SW_HIDE, 2) While 1 $DirData = StdoutRead($DirOutput) If @error Then ExitLoop If $DirData Then $DirOutputOnce &= $DirData Else Sleep(10) EndIf WEnd ; Remove spaces from output $DirOutputOnce = StringStripWS($DirOutputOnce, 3) ; Split output into array $DirSplit = StringSplit($DirOutputOnce, @CRLF, 1) $NrCopiedInfs = 0 For $i = 1 To $DirSplit[0] If StringInStr($DirSplit[$i], $path_to_drivers) Then $registrystring = StringSplit($DirSplit[$i], ": ", 1) If $registrystring[0] = 2 Then; Testing amount of elements in array, if more then 2 Exits If StringInStr($registrystring[2], $path_to_drivers) Then; Making sure that Drivers path exists in string $drivers_directory = $registrystring[2] $search_ini = FileFindFirstFile($drivers_directory & "\*.inf") If $search_ini = -1 Then Else $dll_exe = DllOpen("setupapi.dll") While 1 $search_file = FileFindNextFile($search_ini) $full_path_to_inf = $drivers_directory & "\" & $search_file If @error Then ExitLoop $dll_result = DllCall($dll_exe, "int", "SetupCopyOEMInf", "str", $full_path_to_inf, "str", "", "int", 1, "int", 8, "str", "", "int", 0, "int", 0, "str", "") If $logging_option = "Advanced" Then If @error = 0 Then _AddLineBox("Inf integration passed: " & $drivers_directory & "\" & $search_file) $NrCopiedInfs = $NrCopiedInfs + 1 ElseIf @error = 1 Then _AddLineBox("Inf integration failed: " & $drivers_directory & "\" & $search_file) ElseIf @error = 2 Or @error = 3 Then _AddLineBox("Unknown return type or Function not found in DLL. Tell author about it!") EndIf EndIf WEnd DllClose($dll_exe) EndIf FileClose($search_ini) EndIf EndIf EndIf Next If $NrCopiedInfs = 1 Then _AddLineBox("SetupCopyOemInf method completed. " & $NrCopiedInfs & " driver was integrated.") If $NrCopiedInfs = 0 Then _AddLineBox("SetupCopyOemInf method completed. No drivers were integrated.") If $NrCopiedInfs <> 0 And $NrCopiedInfs <> 1 Then _AddLineBox("SetupCopyOemInf method completed. " & $NrCopiedInfs & " drivers were integrated.") $DeviceDrivers = "PASSED" EndIf Enjoy

[devilrunner] It uses internal routines written in AutoIt v3 with a slight use of "DIR" command On begining i used Pyron's external programs but as soon someone explained me how those programs works i wrote them in AutoIt. I don't like the SetupCopyOemInf routine either as it's including all the drivers into WINDOWS so in my opinion it's NOT great. But it works [ty628659] Thank you for your offer of help but i seriously don't know how to fix your issue even if i would be working on your computer I am just wondering wtf is wrong Would be nice if someone else could try the exact steps you're doing so i could confirm it's one big BUG that needs fixing, still it would be weird that it doesn't work in your cases at all I don't see where you oculd have done wrong and where the program could be wrong. Especially i'm curious why 7zip doesn't work as it should as i think 7zip is backwards compatible.

Yes i'm working on this issue. I tried to include DLLCALL to 7zip.dll but it has diffrent aproach so would have to rebuild some functions preety heavy. So instead i will try to download driverpacks and test on new ones why the problem with unpacking occurs. As for non-finding unpacked drivers can you check "DIR /A:D /S" in cmd line and paste like first 5 lines or so? Can you also try with drivers unpacked? Just put drivers in clean format if it works? It would be very weird if it doesn't Since i tested that on couple of computers and never had problems.

There's no decompile passphrase for it. I compile it without the ability to decompile. I'm not releasing source until it will be FULLY working release As in not having all the problems issues and when i'm done coding it. It might take a while. In the meantime you could help by testing out current version and trying to spot errors Like the one that other guy has. Wonder if it's only him having it or more ppl does.

That's the whole idea Otherwise it wouldn't be usefull... [21:37:20] - Setting path into registry using RegistryDevicePath method. [21:37:20] - Added to registry: C:\DriversTest\D\C\A [21:37:20] - Added to registry: C:\DriversTest\D\C\AM\1 [21:37:20] - Added to registry: C:\DriversTest\D\C\AM\2 [21:37:20] - Added to registry: C:\DriversTest\D\C\AM\3 etc and so on..

http://oppetid.no/madboy/hardware_0.4.9.exe --> and add in hardware.ini Debug = Yes Now most of the variables should be put in log before they are used and also unpacking and packing have now output so we should be able to tell what's wrong. I also put newest 7zip in it so hopefully problem is gone. Please check it out. Tnx!!!

It's weird. Very weird. I can't reproduce your problem. As i see the times.. [02:32:47] - Unpacking drivers from C:\Test\DP_Sound_B_wnt5_x86-32_606.7z [02:33:12] - Unpacking drivers from C:\Test\DP_WLAN_wnt5_x86-32_605.7z drivers are being unpacked. But since RegistryDevicePath info doesn't "give" output what dirs are added to registry it seems like it doesn't finds the unpacked drivers in C:\DriversTest. Can you check if those were unpackaced successfully into C:\DriversTest? [02:33:36] - Setting path into registry using RegistryDevicePath method. [02:33:37] - Drivers path was set successfully into registry. Rest seems to be working normal. Unknown devices are removed without problem. Btw do you get the 'DUPA' msgbox before Backup of drivers happens? Is the path to 7z.exe correct?

Weird, i reuploaded hardware_0.4.4 but it doesn't seems to be any diffrent. Also i just set this, and tested with some driver packs. I guess i could upload some new 7zip version. Maybe new driver packs are packed diffrently but i very much doubt it. Try my settings but yours look okey and shouldn't need to be changed. Also i hope you have full rights to C: drive and that directory C:\Drivers in your case doesn't exists or exists and is writeable? Ah, and check if 7z.exe can be found in some temp directory in your Documents and settings? My program on start unpacks 7z.exe to temp dir and uses it to unpack. If program still won't act like it should i can add some debug MsgBoxes so we can check what's wrong in your case, of course if you're up to some testing [iNFO] Start=Manual Mode=Standard Drivers_drive=C Drivers_dir=\Test Device_manager=On Method=RegistryDevicePath Logging_to_file=Yes Logging_option=Advanced Drivers_Packed=7zip Copy_drivers=Yes Copy_where=C:\DriversTest Delete_drivers=No Create_backup=No [21:34:28] - =================== Log Start: MYCOMP [21:34:28] - Starting program on MYCOMP. [21:34:28] - Detecting Windows version - Windows XP x32 [21:34:28] - Checking for drivers directory existance. [21:34:28] - Drivers directory (C:\Test) exist. [21:34:28] - Detecting number of devices in system. [21:34:29] - Found 140 devices without any problems. [21:34:29] - Manual start used - Waiting for orders. [21:34:30] - All devices have drivers. There's no need to start program. [21:34:30] - Checking for directory where drivers will be copied. [21:34:30] - Directory (C:\DriversTest) already exists. Using it. [21:34:30] - Searching for 7zip archives in C:\Test [21:34:30] - Unpacking drivers from C:\Test\DP_Chipset_wnt5_x86-32_605.7z [21:34:37] - Unpacking drivers from C:\Test\DP_Graphics_B_wnt5_x86-32_603.7z [21:35:55] - Unpacking drivers from C:\Test\DP_Graphics_C_wnt5_x86-32_603.7z [21:36:35] - Unpacking drivers from C:\Test\DP_LAN_wnt5_x86-32_6051.7z [21:36:58] - Unpacking drivers from C:\Test\DP_MassStorage_wnt5_x86-32_6031.7z [21:37:20] - Setting Driver signing to OFF. [21:37:20] - Setting path into registry using RegistryDevicePath method. [21:37:20] - Added to registry: C:\DriversTest\D\C\A [21:37:20] - Added to registry: C:\DriversTest\D\C\AM\1 [21:37:20] - Added to registry: C:\DriversTest\D\C\AM\2 [21:37:20] - Added to registry: C:\DriversTest\D\C\AM\3 etc

Adding Remove & Rescan just for graphic card is not an easy task, well codewise it's not so bad but i would have to implement searching procedure for all graphic cards. So i would have to have their Device ID. I guess there are like 32+ graphic cards which means having my program scanning thru every device id and trying to match it. Then when matched remove it. And here starts the hard part, after removal you rescan for p&p, but from now it's mostly Windows job to catch the right driver and i guess it would pickup the one that it finds first ? Of course i could probably reset the path for searching for drivers so it wouldn't search in C:\Windows\System32 but most of the time it would be preety stupid idea on my part. My program isn't realy typical for use at home where usually ppl have great graphic cards and new drivers every few weeks/months. It's mostly build for IT Department use when they have a lot of hardware, diffrent computers and usually if some drivers work they leave it like that. So they can prepare CD or DVD or USB-PEN (fastest solution if u ask me) with drivers they have for each laptop/computer and they just use it. Usually those computers are supposed to work so ppl can "WORK", not play games or so That's why that request is a bit questionable Also preparing drivers, testing and using my program just once a year isn't realy worth the time you have to put in it. While at IT Dept you use it daily putting some work into it will shortly bring effects. Hope you understand. If you would realy need it thou i can give you hints how to achieve it. But i realy don't see the purpose of making that addon What i want to add is so the program would 'check' if removed hardware needs reboot to apply drivers or not. That and few other things i want to add. Just a bit lack of time and doing other programs for myself.

Thanks, i got msg from one of the users that the pop-up wizard in his case still pops up. It's weird. I tested it on Fujitsu-Siemens S7010 with like 7 drivers not installed and only Bluetooth didn't installed itself (but with BT there's some problem that even bigger companies can't realy solve as Microsoft doesn't sing it at all). I want the "manual" use to work perfect so i can just work on unattended mode so it can be used with switches and so it can be used easly in some advanced configuration. I was thinking about using autoit functionality to just press buttons/navigate mouse etc so unsigned drivers can be taken care also with it (and eventually wizards if any comes up). I'm not sure it's good idea thou. Maybe someone has better or thinks it's a good one?

Release 0.4.4 is out. Please test it as it should fix the wizard problem that popped out even thou it wasn't nessecary. So please let me know. Possible changes in next versions: - Better handling of removed devices. Especially those that require reboot to work. Changelog for 0.4.4 - Possibly fixed problem with Wizard poping-out when not nessecary. Need Feedback so lemme know. - Completly new Plug & Play redetection handling (thru DLLCALL) - tnx to AUTOIT Forum.

Well it's not realy in power of my program. It's more like windows behaviour. What can be done is to check if there are registry entries that could disable that behaviour or eventually implement, what in autoit3 shouldn't be problem automatic 'click' next next next so user interaction wouldn't be required. I'll have to look at it. I don't realy want to use 'screen interaction' as this won't be 'nice hack'. It will be visible for user which makes the program a bit unproffesional, but it also might be the only way I've seen some drivers getting installed that way, like Toshiba bluetooth which was using similar way to interact with windows questions, but it was ugly to me. I'll try to see how to fix problem, but i lack time latly since i am in the middle of changing jobs and i have other responsibilities now.