nonspin

I'll make it short: DO NOT TOUCH THIS ADDON. Why? For example, have look into "NDP461-KB3154529-x86-x64.reg" This is just one sloppy piece which is capable of cross-contermining systems. The .reg contains ABSOLUTE PATHs, "C:\windows\". Now what will happen if you setup windows on D: -- next to your current one ?. How long will it take to screw up BOTH systems, because trying to clean the setup on D:\ also screws with c:\ Now what are the odds, since the author couldn't be bothered to use %windir%, that everything else is as sloppy ? I'll advice everyone to setup chocolatey at at startup batching everything crucial - like "choco inst powershell" would deal with everything: removing wMF4, insfalling WMF5, DOTNET4.5 and Powershell 5..

Using the "Downloads" from inside of your WinToolkit application to access - let's say ISO's, -> in an unregistered state -> ad.fly redirection is enabled. Once you have registered your copy of WinToolkit - those ad.fly redirects go away. However, ad.fly is just a 5 second advertising placeholder (watch the countdown at the top-right of your page). Once it hits "0" - you can proceed to the initial target. This is common practice and has nothing to do with malware or infected code.

SecureBoot and all the CSM functionality doesn't have any effect on Win 7. Also UEFI-Boot doesn't work on any other than FAT32. UEFI doesn't do anything to your Boot-functionality (other than forcing it into FAT32) and it does not magically turn your USB into a magic carpet. Therefore - rethink your approach and opt for compatibility

http://www.wincert.net/tips has no index or 301 redirect set - therefore ends in 404 Everything below is fine: http://www.wincert.net/tips/microsoft-windows

*bump*

The original format is <Highpart> & <Lowpart> From there - w32time - will convert it to whatever Location/Region is set. Each Location/Region has a defaul Format according to the Language. for example: Location: UK Default Format: English (United Kingdom) Short Date: dd/MM/yyyy Location: JP Default Format: Japanese (Japan) Short Date: yyyy/MM/dd

How much of a difference (MB) is there ?

When closing WTK via TaskManager, sometimes temp-files get stuck in a corrupt state. After executing WTK, it looks for previous configs .. also trying to process the corrupt one(s) - which it doesn't like and commits suicide

That's why i use a service to handle 3rd-party/custom themes - rather than patching the files. ;D

You could skip all the tasks converting times. Simply copy whatever is inside <LASTMODIFICATIONTIME> and replace it with whatever is inside <CREATIONTIME> for example: copy the part in red to notedpad <LASTMODIFICATIONTIME> <HIGHPART>0x01CF83B1</HIGHPART><LOWPART>0xE5F87098</LOWPART> </LASTMODIFICATIONTIME> paste it to: <CREATIONTIME> <HIGHPART>0x01CF83B1</HIGHPART><LOWPART>0xE5F87098</LOWPART> </CREATIONTIME> This would also reflect the REAL time it was modified and not the value you have generated

Had a look into wimlib ? I think it's an alternative worth considering. http://sourceforge.net/projects/wimlib/

you mean Date/Time to Integer8? (remove .txt from attached file) Usage (from CMD) cscript DateToInteger8.vbs "06/09/2014 10:30:00 PM" result: Integer8 value: 130468194000000000 (decimal output) -> use calc.exe (programmer mode) to convert to hex (QWORD) -> 1CF842195DB5400 highpart:01CF8421 lowpart:95DB5400 validation: w32tm /ntte 0x1CF842195DB5400 151004 20:30:00.0000000 - 6/9/2014 10:30:00 PM DateToInteger8.vbs.txt

w32tm /ntte 0x1CF83BD00A67400 151004 08:30:00.0000000 - 6/9/2014 10:30:00 AM 151004 08:30:00. <- GMT ... 6/9/2014 10:30:00 AM <- relative to GMT (system setting > GMT+2)

Highpart/Lowpart explanation: Highpart: Date Lowpart: Time convert/verify: w32tm example: <CREATIONTIME><HIGHPART>0x01CB88D1</HIGHPART><LOWPART>0xDB7CCA61</LOWPART></CREATIONTIME>syntax: w32tm /ntte 0xHIGHPARTLOWPART Open DOS-Box: (Win+R) CMD w32tm /ntte 0x01CB88D1DB7CCA61 149707 16:42:02.2122081 - 11/20/2010 6:42:02 PM

ahh, now it makes sense here. Thing is, that i never had issues with the displayed date, because i always apply a custom boot layer to get my USB3 to work properly. Therefore it never showed the wrong date in the setup.

Whenever i add updates it reflects that in showing the date i added them. Hence "date modified"

In that case, why don't you include the ImageSource date in the title (Operating System) ? .. Or better yet, in the description field displaying after you hightlight the item. It's also the most promising to actually being editable since the extraction and modifying of the dates isn't that easy. Then you would have both types of information visible and not confuse anyone - including yourself. Editing the modification date to something only you know the means to isn't of much help or value. In a perfect world, you would edit the resources of setup and display both items - date created and date modified.

CreationTime is not what you want to edit and expect any results. LastModified or LastModificationTime is the entry that gets displayed. Maybe it's just me, but why would you even want to edit it ? It is the one visible information that tells you how old the image is you are about to install.

The 7z-SFX compression strength is not relevant - it's the self-test verification and a present encryption. Most authors use "protect SFX (with password)" to prevent manual unpacking .. Now, it would use the password as an encryption key .. Makes sense, right ? Upon execution it would first decrypt large chunks in your RAM and verify the contents ...

Try Attribute Changer -> http://www.petges.lu/home/ If doesn't work this way, you have to edit the PE_Header or the .xml entry <LASTMODIFICATIONTIME><HIGHPART>0x01CF6C3D</HIGHPART><LOWPART>0x3FF13CBB</LOWPART></LASTMODIFICATIONTIME>example: 0x538A7B10 = June, 1st 2014 01:00:00 AM

If "Allow 3rd Party Themes" is used, does WT patch the .dll's or do you add a service to handle unsigned themes ?

There are plenty of ways to so: - On execution WinToolkit.exe you would spawn one addional process hooking ExitProcess for example waiting for the correct trigger and then deleting the file .. i could come up with at least 5 more ways.. , but i'm pretty sure it unpacks somewhere into 2 or more files and just waits for the child process to close it and dekete the file before executing the actual Wintoolkit.exe ... upload the file to VT and post the report ... or send me link to the file via PM and i'll analyse it and tell you exactly what it does and what it may have done to your system

"The application in 0xfc62xxx" is most likely a windows .dll (most likely shell32 or explorerframe) .. Since it says "written" and your Windows is german - it looks like the Themepatch applied something wrong.. Boot into safe-mode with prompt and run SFC /scannow

Fill form by selecting (target) .exe Almost all fields <info> can be retrieved from the application/executable easily. It would speed up creation significantly. Creator could be automatically set to %USERNAME%

Something is still not right, though. I did a very simple integration job to narrow down the problem job: W7x64 ENT + USB3 - en_windows_7_enterprise_with_sp1_x64_dvd_u_677651 (untouched) - Intel® USB 3.0 eXtensible Host Controller: 1.0.10.255 - Asmedia_USB3_V11430_XPWin7 (official ASUS) No errors during integration. Asus Maximus-V Gene Test1: Booting from Intel USB3 - Shows "CD/DVD Driver missing" aftrer LanguageSelection - Selecting "Browse" shows all HDD's and X:Boot (boot.wim) - The actual USB3 Drive is NOT present FAILED! Test2: Booting from ASMedia USB3 - same as above FAILED! Test3: Booting from Intel USB (normal non USB3) - SUCCESS, but: In Windows7 -> DeviceManager the Interl-USB3 shows as "Unknown Device" even after pluggin a device to wake it up. Now, applying the very same Drivers, which WTK has "successfully" integrated the USB Hub wakes up. -> Manual Driver Installion via Device Manager (.inf) I suspect, that WTK separates the "Intel® USB 3.0 eXtensible Host Controller" from "Intel® USB 3.0 Root Hub" and stores one part in the boot.win - the other in install.wim. That's the only logical explanation i can come up with.