Jump to content

ceztko

Member
  • Posts

    22
  • Joined

  • Last visited

  • Donations

    $0.00 

Posts posted by ceztko

  1. Hello,

    I was having the same problem (the invalid INF section), and I believe I have solved the mystery - well at least it worked for me :)

    I basically expanded the mdmcpq.inf file from my unmodified XP CD, and put it in the INF subdir of my XP installation, and ta-da! The driver got finally installed.

    Confirmed! It works. I had to add the "usbser.sys" driver. Summarizing, 2 files are needed: mdmcpq.inf (put it in \windows\inf) and usbser.sys (put it in \windows\system32\drivers). I think nlite function to leave files on the resulting media should work. Thanks Slurpymeister.

  2. I have a Dell XP Pro SP2 CD that came with my Dell XPS410. I can boot from the CD and install XP with no problems. I used Nlite to add SP3 and only SP3. It will boot from this CD and copy files. However, when it gets to the starting windows screen, I get a BSOD with a reference to "7b". I have attemped this several times, a few times adding the ACHI SATA drivers. No go!

    I have tried the manual method of slipstreaming with the same result.

    Any help would be appreciated!

    The easy way? Download an original windows xp pro image from p2p. If you fear of legal implications, consider that you are already elegible of owning an un-customized copy. Nlite can't support any existent broken xp build.

  3. The EULA was put there for your protection more than Nuhi's.

    I can agree but...

    Now you boss is pi**ed because you used an app you can't provide support for and your out of a job and possibly in court, while they are looking at sue-ing Nuhi too.

    ...

    Besides while the app is not illegal some of what it does is illegal as it COMPLETLY breaks the MS eula! These things are stuff a personal user can get away with but MS will notice and sue YOUR company if all of a sudden the get 1000 or more error reports, service calls because you f'ed up the windows build you had the balls to use at work.

    These are, frankly, exaggerations. The max that can happen with your job is you loose your job (*). The max that can happen to nuhi is nothing: "NO WARRANTY" on the license is more than enough for him. The max that can happen with MS is you loose the warranty. Loosing warranty is all another issue: if you have licenses for 1000 pc, and you sign a proper support contract with MS (such as Premium Support), you can probably afford using MS supported tools, such as the cited OPK. If you own, let's say, 30 standard WXP licenses for your job, without any further support contract, from a sysadmin prospective (your grandmother probably doesn't use nlite on his home pc anyway :rolleyes: ) loosing warranty on the OS, and with software in general, can't be considered an issue: if you find a bug on a nlited windows that is reproducible on a standard windows buid, and report it to MS, you basically have the same opportunities it will be fixed promptly. And if you need tech help (always from a sysadmin/power user perspective), I don't think it's available without signing proper support contracts.

    Another situation: one want to use nlited windows for embedded purpouse. This is stupid:

    1) WXP (or W2K) itself isn't suitable for embedded applications;

    2) You don't have any kind of Tech Help Support from MS.

    EDIT: (*) Here I am assuming no sysadmin would be so stupid to use nlite in mission critical applicances, e.g. medical, air-traffic controlo appliances...

    while I don't see any problem in using nlite on universities computer networks (that may be very big).

  4. About the second one, I think it could not even be enforceable, if present in the EULA...

    OT:

    Just read the EULA. IANAL, but I'm pretty sure some clauses can't be enforced:

    5. nLite is free for personal use only, you cannot use it for any company or business purposes at this time.

    This kind of clauses have never been proved as valid in trials. As long I think M$ can't sue me for what I'm producing (and where I'm using it) with Word, Excel or Access, I assume I can't be sued if am using a nlited build in my job. The customized windows build, in fact, is just the product of nlite, not nlite itself. Even nlite custom script that may be present in the build probably can't pose a restriction on the use of a nlited windows build, for the same reason MS can't limit the usage of my OpenXML files just because MS products wrote the XML skeleton of them. They may still be subjected to copyright, so yes...I may not be allowed to copy those script, but this is not a problem. Probably there are even better examples.

    You may not decompile, disassemble or otherwise reverse engineer this product

    It's a long standing myth that's so easy to put a clause of this kind on your License Agreement to give you easy win on trials in case of so called "reverse engineering". If I want, I'm perfectly allowed to study just the build of Windows (without reading any nlite custom script) to learn what nlite is doing to it and reimplement the same behaviour in similar program, a "clone" of nlite. This reverse engineering technique is called clean room design, ofen used by companies that want to create compatible products and it's perfectly legal (for example, Intel reverse engineered x86-64 set of istructions to produce their 64 bit compatible cpus).

  5. The problem is our method cannot be used when the update is a MSI Installation EXE (file has package icon). We get an switch error msg. So we manually install these updates at the User Desktop, via Win Updates.

    Will nLite Slipstream (aka execute) MSI Installations by executing the EXE?

    Essentially I want to have .NET (2 SP1 & 3 SP1) installed as part of WinXP setup.

    Do I run the MSI Installations during the SP step or hotfix step?

    Too complicated and out of the purpouse of nlite. Read this WONDERFUL guide about RunOnceEx. There's even an explanation on how to use it during T-12 minute stage of Windows XP Setup. WARNING: if you don't use nlite to customize your build, .net 3 won't installable during Setup. This is caused by some registry keys that are not fully setted up on that stage: nlite processing fix this.

  6. Read nLite EULA. nLite is not for commercial use.

    Cheers ;)

    One point is using nlite as part of the product you make and sell. Another is using nlite to create customized windows builds for your daily work.

    I believe the first is prohibited. About the second one, I think it could not even be enforceable, if present in the EULA...

  7. FFFFFF9D doesn't work on Win2000 SP2 (I think it was 2) and later OS's. I think I read about a patch that uses that value to make SFC switchable in the registry, but for the life of me can't remember where I read it. Maybe here somewhere or at RyanVM's board. *EDIT* Or was it XPLite?

    Yes, it's XPLite. If you see the site linked in my first post P.S., it's described how to patch sfc-os.dll to make WFP switchable like xp-lite does. It's this patched version I'm using now. janedoe's patch does work, but it does disable WFP definitively without registry modifications, like nlite does.

    From my experience with nLite, although Nuhi invested tremendeous efforts in fixing the popups (around the time of the news article you pointed to in your first post), SFC enabled still doesn't work quite right. Maybe it was fixed in the very latest version (and you say it isn't :) ), but since that time I gave up and just use SFC disabled.

    The registry modify in this post does work with stopping useless pop-ups :D . Again: at least with my sfc-os.dll, dunno with an unpatched one. The only problem I have with it is that I can't have it available at the first boot, as winlogon.exe is resetting it to 0. Only once: if I set it after first boot, it remains on the next ones.

  8. Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
    "SFCDisable"=dword:00000004

    To quote myself, it seems that setting this key during the install doesn't surive the first boot :( Something is setting it again to dword:00000000 just before the installer reboot the system. :( This is not so good as the setting requires a reboot to apply. If someone knows how to make it surviving the first boot, it would help much.

    EDIT: "Almost" confirmed. Citing this site, speaking about SFCDisable=dword:ffffff9d value in W2K:

    ... Jeremy rebooted a few more times and verified that it is the one value (other than 4=popus disabled) that is not reset to 0 after the first boot.

    Well, seems that M$ added another "feature" and now 4 is another value resetted to 0 after the first boot. If someone knows how to circunvent this, but I have some suspects it is hardcoded...

  9. Good idea, but what will happen if driver signing policy is set to or reverts to warn (or God forbid, block)? I've seen it happen many times, with or without nLite. Won't it result with mixed files after installation of non-signed drivers?

    I don't think WFP applies to driver signing policy (and viceversa). A driver simply shouldn't touch system files, that are in a diferent set, so the user is always allowed to load unsigned drivers, unless the policy is set to block. This is true even in a unpatched system.

    but IMO it's always better to see what is going on.

    You are right, but the problem is that the WFP pop-ups windows arising in a nlited system:

    - are absolutely non-informative: if you are able to consult windows logs (I am not and I don't care; I take a look only at my /var/log/messages :D ), they can probably help you more;

    - they aren't really informing you that someone is trying to ovewrite a files in the system and what files. They are just reminders that you have patched/modified files on your system (and after nlite processing they can be IE7, WMP11 files or sfc-os.dll, uxtheme.dll, etc...). They appears only once on a running system and they come back again the next time you reboot. The reason why they are appearing in particular moment? Because you are overwriting (or some other tools for you) a WFP protected file, yes... but if the file overwritten is correctly present in the dllcache, it will be anyway replaced after you answer yes/no to the pop-ups. The next time you'll overwrite any other WFP protect file in the current session, you won't get any other reminder, and the file will be silently replaced. Try yourself.

  10. Taking a look at the news archive page, I saw that many complained in the past about Windows File Protection Pop-ups after nlite processing. It was recently my case, using the just released nlite 1.4.7: I integrated ie7, wmp11, a patched sfc-os.dll and now every time some stupid installer touch system files I got 3-4 WFP pop-ups... But it's just because I know of stupid installers that I want to keep WFP enabled, as most people should do. Understanting that they are just warnings, not errors, I remembered of this little tweak:

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
    "SFCDisable"=dword:00000004

    Where SFCDisable=4 is "enabled, with popups disabled". It works perfectly (seems that even M$ devs like their systems tweaked, after all :rolleyes: ): WFP works and no stupid pop-ups that you, nuhi, can't fix for every possibile situation (or at least we can't ask you to do so...). Why don't you integrate this tweak in nlite?

    P.S.: A small clarification: I am using this patched sfc-os.dll that fully respects values of SFCDisable. Not sure if the original sfc-os.dll respects SFCDisable=4.

  11. Hi! I'm trying to replace sfc-os.dll on a windows xp sp3 media build with a patched one that permit switching of the windows file protection (so is not exactly the wfp disable patch that is already on nlite). I tryed 2 methods:

    - I tryed to put the file on the $OEM$/$$/system32 and $OEM$/$$/system32/dllcache dirs. If this method has ever worked, well... now it stopped. The wfp is active when copying $OEM$ dirs, so the file is getting replaced by the orginal compressed sfc-os.dl_ version;

    - I tyred to compress my edited sfc-os.dll with makecab and putting it in the i386 dir. This is described as a working method in many sites. Well, for me it hasn't worked: while trying to copy the files from cd to hd (the first phase after partitioning; sorry don't know the correct phase name), it stopped exactly at that file. Can't say if the installer wasn't able to expand it or it detected it was edited so refused it.

    Can you tell me a working method to replace WFP protected files on i386 dir in recent windows versions? Could putting the un-compressed file on the i386 dir (even after nlite processing) works?

    Sorry, but I don't want to waste other dvds (I'm not using a vm...), and can't find up-to date infos googling around.

    Thanks,

    Francesco

  12. I'll keep you informed.

    Confirmed, I was overwriting the modified sysoc.inf with my own. If I can give an advice, when WMP11 slipstreamer finish its job, in the pop-up window the user could be warned on modifying files such as wbemoc.inf, svcpack.inf and sysoc.inf. In my case, I hadn't any clue WMP11 slipstreamer was modyfing sysoc.inf.

    Thanks for the prompt help (and you and Boooggy for the great app)!!!

    Francesco

  13. If you compare both sets of files, the 2 wbemoc.inf are identical, except that nLite just stripped all comments from the file (and it seems you removed System Restore and Security Center with it).

    If you compare both SVCPACK.INF, they are formatted correctly...

    It seems that there is a broken addon you are integrating that is breaking your SYSOC.INF, so when WMP.INF is trying to register itself, the file isn't there. This is not the slipstreamer's fault. (only then it was because it was editing wbemoc.inf incorrectly, but this has been fixed since).

    I AM breaking my own SYSOC.INF :lol: . I have a modified, already processed by nlite, sysoc.inf in my $OEM$/$$/Inf directory. This is because I am adding the W2K IIS to the WXP HOME build. If you are telling me that wmp slipstreamer needs some modifications to sysoc.inf, good: I just know what to do! :angel Thanks for the moment, I'll keep you informed.

  14. To help debugging, here is my wbemoc.inf after WMP11 slipstreamer processing (wbemoc-wmp11-slip.inf), after nlite processing (WBEMOC-nlite.INF), svcpack after WMP11 slipstreamer processing (SVCPACK_wmp11_slip.inf), svcpack after nlite processing (SVCPACK.INF). Consider I first run WMP11 slipstreamer alone, and after I run nlite on the processed source.

    wbemoc_wmp11_slip.inf

    WBEMOC_nlite.INF

    SVCPACK.INF

    SVCPACK_wmp11_slip.inf

  15. I think the easiest way to fix this would be to manually add it to txtsetup.sif and i386...

    I already know how to workaround this issue. The problem is: "Keep files" section in nlite doesn't work for files in driver.cab, as it should. This seems to me a bug: how can i report the bug to the author so i'm sure he's aware of the problem? :rolleyes:

  16. Why not just list agp440.sys in the "Keep files" section in Remove Components?

    It didn't work! Have this in my conf:

    ...
    [KeepFiles]
    msconfig.exe
    agp440.sys
    ...

    agp440.sys is still missing from driver.cab and i386 dir. Is "Keep Files" broken for drivers' files???

    Thanks,

    ceztko

  17. Why not just list agp440.sys in the "Keep files" section in Remove Components?

    Well, i supposed there were needed other files, like *.inf or *.cat. The truth is that if you simply copy this file in system32, you fix a "broken" system, but i don't know if this is a clean method or only a workaround. Anyway, i didn't know that section :whistle: Assuming it does work with files in driver.cab, should be fine for me.

    Thank you!

  18. Hi! This is not obviously a nlite bug, but a stupid policy in intel chipset drivers releases: file agp440.sys, presumably responsabile for agp440 service driver, is missing in a windows xp customized build made with "Agp Filters" checked in nlite and a replacement can't be found in official intel chipset drivers integrated into the build.

    I don't know how much work will be necessary, but would be possibile to trucate the selection of drivers in "Agp filters" and permit another specific check for "Intel Agp filters", considering this very special case of drivers available only in the original distribution? Unfortunately, simply unchecking "Agp filters" is not an option for me, because i need it for other computers that needs this to install older version of Via chipset drivers.

    Thanks a lot for the attention and for this wonderful tool!

    Francesco, "ceztko"

    UPDATE: Title changed, see below.



×
×
  • Create New...