Jump to content

Nasty nLite bug

Ikari

By Ikari
in nLite

 Share

Recommended Posts

Ikari

Ikari

Posted
Posted (edited)

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.

Edited by nuhi
Link to comment
Share on other sites

nuhi

nuhi

Posted
Posted

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?

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

And make sure that NTFS permissions are not tampered with.

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

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.

Link to comment
Share on other sites
Ikari

Ikari

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
Ikari

Ikari

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
Speeddymon

Speeddymon

Posted
Posted

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.

Link to comment
Share on other sites
nuhi

nuhi

Posted
Posted

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.

Speeddymon, it's unrelated to .Net. SP1 is even better.

Link to comment
Share on other sites
Ikari

Ikari

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
johnhc

johnhc

Posted
Posted

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

Link to comment
Share on other sites
Ikari

Ikari

Posted
  • Author
Posted
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?

Link to comment
Share on other sites
johnhc

johnhc

Posted
Posted

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.

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

Enjoy....John

Link to comment
Share on other sites
Ikari

Ikari

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
tap52384

tap52384

Posted
Posted
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.

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.

Additionally, your responses to assistance could be fine-tuned. People genuinely trying to help do not deserve attitude.

Link to comment
Share on other sites
Ikari

Ikari

Posted
  • Author
Posted
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?

Link to comment
Share on other sites
Ikari

Ikari

Posted
  • Author
Posted
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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...