That addon works just fine in v.*67. Ask me how I know

I think you're using a x86 OS..

I've found the problem : .exe based addons don't work when x86 arc is wroten in tasks.txt when integrating in a x64 os based.

The same addon with x64 in tasks.txt works fine in v.*67 in a x64 os based...

So installer both architectur compatible included in addon with x86 line in tasks.txt appears to not work with x64 OS

THX

ps : sorry for my bad english :shy:

Edited September 8, 201213 yr by geromichi

I'm guessing its the registry entry which adds the RunOnce not getting added to the correct place.

Found the issue and it's now been fixed.

Great! Also, I think you forgot about this cosmetic issue two pages back...

the ENE USB Mass Storage 5.89.0.71 (that you can find here as an individual driver, and also you can see it's for windows 7), comes up yellow. This is only valid for the x86 version in an x86 environment, everything is fine in a x64 environment with the x64 driver.

This is also present in v68. Once again, only a cosmetic issue, but maybe you can add an exception so it won't come up yellow.

Also, in v68 now I consider there is a new problem by design. I've tried in this thread to confirm that even in LDR mode the KB2685811 and KB2685813 generated explorer issues are still present, but you chose to ignore this. So please at least add a warning so users can be informed about the matter (a warning like ''even in LDR mode these two update can generate explorer issues for some hardware & software configurations"), so users may remove them from the integrating list manually.

new v.*68 is really slow, in my case it took 38min., when it usually takes under 20min. and i tested it twice, just to make sure it isn't "operator error".

No more addon problem for me with v.*68 : great work :dancing:

About the slowness issues, I think it's related to the new temp folder location via options.

I tried to change the location from D:/WinToolkit (the partition that was auto-detected as having the most free space) to C:/WinToolkit, but the app has the usual behaviour to erase the folder after unmounting. So guess what: after I've run for the first time AIO, on C:, mount-integrate-unmount, and opening the app again and not detecting any temp folder on C: (the app erased it on the previous run), so the app once again had the temp folder set on D: by default.

At least this behaviour is weird so the current implementation is faulty. Maybe smth like a single choice in the options to change only the partition you want for Win Toolkit to ''operate'' on, that also remains unchanged, no matter how many times you run the app.

Suggestion for users with ''slowness'' issues - If you have an SSD, make (sure) the app has its folders (via options) on the SSD partition EVERY time you open the app. If you have a HDD, make sure you have those folders on the first partition - C:, the same as the original copied windows files.

Thanks for the tip RicaNeaga

I unplugged external HD in my laptop and now it uses my SSD. All done in 18m56s

You're welcome.

Another thought for this default option - maybe if the C: partition has at least 25 GB free, then choose C: for the temp folder. And if it has less, then scan for another partition... This would also pre-solve the potential slowness problems.

I don't know what the reason in the first place to make this option, Lego, but please reconsider it.

I can't understand this complain about temp-folder-placing!

If you don' want that WinToolkit search for you the biggest free partition, you can set, where WT has to place

temp- and mount-folder: this path will be written in the setting txt and used on all the next runs.

Regards, Thiersee

this path will be written in the setting txt and used on all the next runs

If you would have read what I've said you would have understood that this is not the case. So to understand you really need to read. Not reading equals not understanding.

Also, if a user has an external HDD attached, or a very fragmented (but with ''tons of free'' space) partition, then Win Toolkit processes will become very slow.

If you would have read what I've said you would have understood that this is not the case. So to understand you really need to read. Not reading equals not understanding.

Also, if a user has an external HDD attached, or a very fragmented (but with ''tons of free'' space) partition, then Win Toolkit processes will become very slow.

I have read, what you wrote and I'm still not understanding, because on my installation WT writes the chnages in the setting.txt.

BTW, I have 2 HDDs attached and I DON'T use the auto-feature.

Great! Also, I think you forgot about this cosmetic issue two pages back...

This is also present in v68. Once again, only a cosmetic issue, but maybe you can add an exception so it won't come up yellow.

Also, in v68 now I consider there is a new problem by design. I've tried in this thread to confirm that even in LDR mode the KB2685811 and KB2685813 generated explorer issues are still present, but you chose to ignore this. So please at least add a warning so users can be informed about the matter (a warning like ''even in LDR mode these two update can generate explorer issues for some hardware & software configurations"), so users may remove them from the integrating list manually.

It doesn't appear yellow to me, works completely fine.

Also Win Toolkit will only selected from 'Fixed' drives so external HDDs should not be selected.

P.S. Since everyone is dumping there issues into this one thread and making everything complicated, i'm going to lose this thread. If have used the latest version and still have issues then please make a new thread which should have happened in the first place...