Jump to content

Ikari

Member
  • Posts

    20
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Germany

Posts posted by Ikari

  1. Ikari,

    What is your E drive? You’re not trying to write to your original Windows CD, are you?

    John

    No, of course not :blink:

    On E: are all the setups for programs, it's a normal HD partition.

  2. Here's my collection of security updates for XP 64 SP2, also compatible with Windows Server 2003 SP2 64-bit, with all security updates up to this month (March).

    With this, you can have an up-to-date install and don't need to go to Windows Update anymore to download who knows how much, and then install it all, so it saves a lot of time :w00t:

    Premium content which requires a validation is not included. Also not included are updates to Windows Update, as they're different for XP 64 and Windows Server 2003 64-bit, so you would need two different packs with them included.

    Download here

    btw: You can also use RyanVM Integrator 1.5 for this.

  3. Try using Unlocker 1.8.6 on the file you are receiving an error about. Since you rebooted and the same error occurred, it's possible that it is a program that launches at boot.

    I've already tried to use Unlocker, but it will not run at all on my system, probably because it's 32-bit only and doesn't have a 64-bit driver for XP 64 :(

    Do you know an alternative with 64-bit support?

  4. Ikari,

    I don't have Processor Explorer on this machine, so this is from memory:

    Open Processor Explorer

    Click on Find Handle (at the top)

    Paste or type in the complete file name

    Hit enter or click the button.

    Ok, I did that, but it doesn't show any results when I enter the filename and click "Search"... Strange :blink:

    Do you have Comodo Firewall? If so, look at your pending files for the offending file name.

    Enjoy....John

    No, I don't have it. Also, the exception even occurs with no background apps running, so (theoretically) there should be no other app to keep the handle on the files.

  5. Ikari,

    Have you tried using Process Explorer to see what process is holding the handle on the file? I had a similar problem (XP x64) and found that the file was on the Comodo FW 'Pending Files' list. Removing the file from the list fixed the problem but also the problem often went away by simply quitting and restarting nLite (1.4.1). I am not familiar with the MS error reporting terminology, but if I read it literally, it seems to be some kind of I/O error.

    Good luck.........John

    I've already tried nuhi's test version, and while it's an improvement, it still gives an exception about a file being used by a different process, without any running background apps :unsure:

    I already have Process Explorer - how can I find out which process is currently using the file in question?

  6. I noticed you said you installed .net 2.0 SP1 .. You didn't happen to mention whether it is x86 or x64 framework. That can cause a huge difference. Please specify which you installed, and also try reinstalling it, as it may have gotten corrupted.

    Well, duh... If you would've looked at the left, you would've seen that I'm running XP 64, so I obviously installed the x64 version.

    Ikari, it has to make the file and then "makecab it". It is not by accident. I could move that to temp folder but you would have the same issue, I thing that it fails for you on cabinet decompression or compression.

    Heck I can make you a test version then we can see, I will send you a PM.

    Answered your PM already. Just send the test version over.

  7. Here's the language file which fixes the linguistic glitches found in nLite ;)

    Until nuhi gets around to integrate it into the program, simply unzip the attached file and put it into your 'nLite\Lang' directory and select "English2" from the dropdown menu upon startup.

    edit:

    Updated file. Please re-download.

    English2.zip

  8. Here are instructions so you can patch it for yourself with the limit you want:

    Hex (Offset) Mod Original
    00000148 1B 26
    00000149 7E 7D
    000B85CC FF 0A
    000B85CD FF 00
    000B85CE FF 00

    The first two (148 & 149) are the checksum of the file, the others are the limit (hexadecimal).

    Above example uses a 65k limit. If you want to use a smaller limit, you need to calculate the correct checksum again (e.g. with pechksum).

    Edit & replace it in Safe Mode.

  9. Am I the only one who thinks that this forum is misplaced and should be placed under Windows 2003, as XP 64 based on Windows 2003?

    Having it listed under XP, even though it's not based on XP, looks somehow unprofessional :o

    I just wonder which sort of mad reasoning went on in the heads of MS so that, instead of a more fitting "Windows 2003 Professional", they named it "XP 64" :blink::wacko:

  10. XP 64, by a long margin! :thumbup

    I tried out Vista after it came out and was very disappointed. It has severely lacking application compatibility and driver support, a lot of things were arbitrarily changed around for no reason at all, it's quite a bit slower than XP (especially with games) and still has lots of flaws: file copying bug, network bugs etc. I would list Uac there as well, but "It's a feature, not a bug" :o

    With XP64, all of my apps work, driver support is fine, and it even feels somewhat snappier than XP 32bit :w00t:

    XP64 will still be supported quite a bit longer than XP, since it's based on Windows 2003.

    I have a an AMD Turion 64 laptop with 4GB memory. I have flopped back and forth with Vista 64 and 32 and have now decided on staying with 32.

    Whoa, "smart" choice :lol:

    Someone should tell you that you can't use 4GB on a 32bit OS.

    Personally I think Vista looks too nice to go back to XP.

    rofl :lol: :lol: :lol:

    One of the worst pro-Vista arguments I've heard yet. You can easily outfit XP with themes to look as good or even better than Vista. There are even several Vista transformation packs, should you wish XP to look the same as Vista.

  11. Ok, I tried it again a few more times, still the same...

    It looks like nLite is creating a lot of .ini files in the XP CD root directory, just to delete them again almost instantly. Further, it does so two times: once at the very beginning, and once when it is preparing stuff for the integration etc.

    Now what I suppose is that the time span between file creation and deletion is too short, and this results in the "Access denied" error. To fix this, you could create the .ini files in the system's temp directory instead and just leave them there (i.e. not delete them). No harm done, and you wouldn't need to create them all over again when prepaing stuff later.

    Doing this would be very simple, and would most probably fix them problem.

  12. Hm, this isn't something common. Could be extract file glitch then the handle keeps the file taken.

    Have you tried recopying clean installation files in the new folder, to start from scratch?

    Yes, several times. No go.

    Also try removing read-only attributes for the whole folder with subfolders and files.

    Also tried that every time.

    And make sure that NTFS permissions are not tampered with.

    I've made sure that "Everyone" has "Full access", that's it not either.

    You did say without background apps, but just to make sure that means you tried without an antivirus if there is any?

    Yes, tried without it.

    Correcting English lingo glitches would be welcomed. The file you would need is in nlite\lang\translation.txt. Then you can send me the corrected one which I would compare and update the changes in the program.

    Ok, I'll look at it then.

  13. As I'm doing a major hardware upgrade and thus will have to install my XP64 (English) anew, I thought I'd create an install using nLite 1.45 beta 2.

    I've installed the newest .net 2.0 SP1 framework.

    However, after launching nLite 1.45 beta 2 I got an unhandled exception (Access denied) right at the very beginning :angry:

    I clicked "Continue", but nothing happened anymore - the app was obviously crashed.

    After closing it, I tried it again, getting the same error. I've then shut down any background apps (you never know), but the error persisted, regardless how often I tried it :realmad:

    Here's a screenshot, together with the full error message:

    nlite-145b2-141-bug1462.png

    See the end of this message for details on invoking 
    just-in-time (JIT) debugging instead of this dialog box.

    ************** Exception Text **************
    System.UnauthorizedAccessException: Access to the path 'E:\xp64nlite\HIVEDEF.INF' is denied.
    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
    at System.IO.File.Delete(String path)
    at . .(String , StringCollection& , Boolean , Boolean )
    at . .()
    at . .()
    at . .WndProc(Message& )
    at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

    I've then rebooted the PC and tried running nLite right away, and surprisingly the error didn't appear right away - however, it did still appear later in the preparing stage:

    nlite-145b2-141-bug2698.png

    See the end of this message for details on invoking 
    just-in-time (JIT) debugging instead of this dialog box.

    ************** Exception Text **************
    System.UnauthorizedAccessException: Access to the path 'E:\xp64nlite\HIVECLS.INF' is denied.
    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
    at System.IO.File.Delete(String path)
    at . .(String , StringCollection& , Boolean , Boolean )
    at . .(Object , EventArgs )
    at System.Windows.Forms.Control.OnEnter(EventArgs e)
    at System.Windows.Forms.Control.NotifyEnter()
    at System.Windows.Forms.ContainerControl.UpdateFocusedControl()

    When I closed the app and an it again after that, it was back to its original behaviour, with the error occuring right at the very beginning, again no matter how often I ran it :realmad:

    One thing I noticed is that it's not always the same file, but it's always an *.inf file, and it's always in the root directory of the xp64 CD.

    After that I've d/led 1.41 final and tried it, just to find that it exposed exactly the same behaviour :angry:

    Also, as I've said already, this happens regardless if any background apps are running or not.

    Could please add exception handling for this "Access denied" error, so you have at least have a "Retry" option, rather than having the app crashing every time?

    By the way: From the one time where it ran after the reboot (up to a certain point) I noticed that some things sound a little... strange :blink:

    You're no native English speaker, I take it? I could offer to fix these linguistic glitches if you give me the language file for nLite ;)

    Other than that, it would be nice if you could add an option so you can pick the fonts you don't want or need for removal.

×
×
  • Create New...