Thank you all for your suggestions and sorry for taking so long to solve this odd, yet most annoying issue.

The entry in the bugtracker: http://bugtracker.driverpacks.net/view.php?id=322

Topic closed.

sum up.  seems like guirunonce is the issue.

sorry if you figured it out already, i've been away!

SaGE

Hi guys
this  little CMD file did a manual KTD, and that does not produce the popup.
(which does not prove a thing either...)

I actually used ALL PLUS ALL third party.
then I put this on the DVD, together with the extracted files it needs to run.

SET TAGFILE=\DSPdsblr.exe

FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%i:%TAGFILE%" SET CDDRIVE=%%i:

%CDDRIVE%\OEM\BIN\7z.exe x -y -aoa %CDDRIVE%\OEM\DP*.7z -o"%SystemRoot%\DriverPacks"

start %CDDRIVE%\DSPdsblr.exe

%CDDRIVE%\makePNF.exe %SystemRoot%\DriverPacks

taskkill /f /im DSPdsblr.exe


%CDDRIVE%\OEM\BIN\DevPath.exe %SystemRoot%\DriverPacks

exit

This is exactly what I've been searching for.  A way to incorporate the DriverPacks on a previous windows install.

Excellent!!!

Quick note. Just wanted to thank you for the great tool Bashrat. Save me from pulling my hair out. But just my observation on the issue. I build from Ryan's, Nlite, then add your packs. After each step I make an iso of my source and test in VMWare. From the Nlite source I have made with both m1 and m2 and KTD on and off. I have noticed the finisher when choosing the GuiRunOnce is where I have been getting the desktop.ini issue. If I use RunOnce at 937 or anywhere else for that matter that I have never got any of the ini issues. Didn't know if that was any help or not. Will keep testing.

Source Win xp2 sp2 eng corporate from technet library.
RyanVM v1.4.2 Integrator w/ UpdatePack2.1.3.7
Nlite 1.0.1
your base 6.10
Iso's crated with RyanVM

Ocammai

You are not using KTD then? Please post your DPsFnshr.ini.

Source Win xp2 sp2 eng corporate from technet library.
RyanVM v1.4.2 Integrator w/ UpdatePack2.1.3.7
Nlite 1.0.1
your base 6.10
Iso's crated with RyanVM

Ocammai

This issue must definitely be related to the fact that when you use KTD, the directories are now moved instead of copied. I do not see HOW that could be caused, but so far everybody reporting this problem (not bug) had it enabled. This is one of the strangest Windows behaviours I've seen so far.

i use nlite 1.01 to handle the fullunattended install - us-en xp sp2
ryanupdate pack.

everything is fine.
i add Bâshrat the Sneaky 6.10 all packs, m2,ktd, qsc
i have the desktop.ini issue at startup and in all the folder under programs

it is reproduceable on vmware and on 3 different machines i tested.

I also get an unrelated issue stating the "could not move drivers from c:\d" to c:\windows\driverpacks\d"  but after i click okay, it moves them ! HA

i'm glad to see i'm not the only one experiencing this.  I sit back and see what turns up.

SaGE

an apology to mikelm.

I am so used to having hidden/system/extentions view to ON, that I had not realised that when I ran a search on a newly KTD'ed machine, I did not have these settings.
This made me think a a file had moved.

Today I realised my mistake.

This explains why I was on a wild goosechase when I looked for localised differences (I do not regret I tried that, it got ruled out that way)

erm, ahem, so we are now looking for the reason these files get 'unhidden", eh?

@ helmi:
i wrote several time how i make my xp cd didn´t i?
here again :-(
1. clean german xp sp2 source home or pro
2. then update with sereby´s updatepack with no addon´s only with option delete kb*.cat
3. then i make from this xp-base with nlite the konfiguration
4. now i supply the driverpack.
5. burn cd

get the desktop.ini issue

Yeah, looks like I mistake your base for the DP BASE, sorry about that.

Anyway, why don't you just give it a try and slipstream the UpdatePack using nLite?
Just for testing purposes...

It certainly can't hurt and should it indeed fix it for you you sort of have achieved your goal, no?

get the desktop.ini issue

as i know the desktop.ini files are in every folder , so there are different content, the problem would be that something during KTD would be break the prozess to set the right attributes to them so they are visible. and only in the autostart folder there is the effekt that the file was shown in editor.  if you set your folder option so that every file would be shown so you see that there is in any folder in the startupmenu a desktop.ini file.

run this script at the startup of windows

SET VERK2PATH=%SYSTEMDRIVE%\DOKUME~1\%USERNAME%
copy %SYSTEMDRIVE%\windows\wegini.bat %VERK2PATH%\Startm~1\Progra~1\Autost~1\wegini.bat"

copy this batch with OEM methode to windir name: wegini.bat

@echo off
SET VERK3PATH=%SYSTEMDRIVE%\DOKUME~1\%USERNAME%
CD /D %Verk3PATH%\Startm~1\
ATTRIB.EXE +R +A +S +H desktop.ini /S /D
DEL /f /q %Verk3PATH%\Startm~1\Progra~1\Autost~1\wegini.bat
exit

this set the attribs from the desktop.ini files right , but at the first startup it pops up on time , because i didn´t find a way to let run my script in autostartfolder bevor the popup comes.

in VPC2007, clean dutch sp2 OEM, DP all on this source with Winnt.sif, KTD all, gets desktop.ini
that's nothing new.
Since Mikelm asked, yes, I had noticed that there is a desktop.ini in program group.
But, it is different than the one in program/startup (I had looked at all those I found when I ran search that other time) OTOH, it is not normal that one finds one there, I realise now.

It does have identical line with that number in it, so there are two, the one that don't popup has more lines.
(I also have this funny feeling it is created after the popup.)

after a clean OEM source setup, that particular ini file we see popup is in windows\system.
with KTD, this moves to startup.
(again, nothing new.)

I have not tried with a PATTERN yet.
I am waiting for the bugfix release, so that we can rule out that D/D thing triggering this.

I would like to know wether PMtimer still runs when PNF is launched.
It is apparently not needed for PNF.
a 945D with 2*2Mb @ 3.4 with 2Gb DDRII dual channel running off a RAID is no slowpoke? (yet, the manual KTD worked flawless.)

what is so hard to understand ?  why i should every time slipstream the updatepack to test some funktions in nlite ?  so i have a  base allready slipstreamd with the updatepack and now it is faster for testing new things , because i didn´t slipstream the updatepack again and again ...

Ok, now I see your point.

Anyway, since you are experiencing problems, I can only urge you to try a completely new, fresh source for bug-tracking.
Everything else is just negligent.

Also, you are making a mistake:
The BASE should always be slipstreamed last, just before creating the ISO.

Do not touch your source with nLite (apart from ISO creating) after that!
At best, only do some minor manual tweaks of which you can be absolutely sure they don't break anything.