• From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Topic: service entry naming conventions

Hi

I've encountered an issue with injecting mass storage drivers into an offline system with peimg due to some inconsistent service naming conventions in inf files. I mention it here: http://www.911cd.net/forums//index.php? … p;p=142608

I've only had a brief look also at some silicon drivers and noticed that some follow the convention of naming the service directly after the sys files. Others such as M\S8 and M\S8A, for example, have the same service name -- ie 'SI3124' -- and so driver injection is not successful.

Can the service in '8ASI3124.inf' be named '8ASI3124' without problems? Likewise the intel drivers? What are the reasons that some services are not named directly after their .sys driver files?

Thanks for your time and help.

Regards,
Galapo.

  • Jaak
  • Old Timer Rookie
  • Offline
  • From: Eeklo, in the East Flanders
  • Registered: 2006-07-23
  • Posts: 3,594

Re: service entry naming conventions

Q1, Can the service in '8ASI3124.inf' be named '8ASI3124' without problems? Likewise the intel drivers?
Q2, What are the reasons that some services are not named directly after their .sys driver files?

Hi,

a1, you can apparently do that.
a2, who is going to test each edit?

The answer was 42?
Kind regards, Jaak.
  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

Now sure what question 1 is aimed at: using peimg to inject drivers, or the renaming of service entries. I renamed the Intel ones and they were installed correctly. On the use of peimg see:
http://www.911cd.net/forums//index.php? … p;p=141778
http://www.911cd.net/forums//index.php? … p;p=141825

I'm just wondering if there is any reasoning behind renaming the .sys files without concomitant naming of service entries. My attempted guess was that in some cames the driver may have failed in tests, but maybe there is no explicit reasoning behind the naming other than current convention.

Regards,
Galapo.

  • Jaak
  • Old Timer Rookie
  • Offline
  • From: Eeklo, in the East Flanders
  • Registered: 2006-07-23
  • Posts: 3,594

Re: service entry naming conventions

One major reason is that we prefer to not have to edit/rename anything.
Let me know if this suits your needs.
link pulled

Last edited by Jaak (2008-02-20 05:43:58)

The answer was 42?
Kind regards, Jaak.
  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

Hi Jaak,

Thanks for taking an interest! I'll take a look shortly at what you've done.

Regards,
Galapo.

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: service entry naming conventions

i thought it was your intention to add single dirvers...

IE a drive is moved to a new machine and needs the driver changed...

you are going to go down in flames on many of these drivers if you try to add them together.

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • Jaak
  • Old Timer Rookie
  • Offline
  • From: Eeklo, in the East Flanders
  • Registered: 2006-07-23
  • Posts: 3,594

Re: service entry naming conventions

It is a problem all sysprep users have..
8024 was not good for live disc install on VIA.

Please thouroughly test this. (you can use a compare tool to see what changes were made)

edit;
testfile for galapo "DP_MassStorage_wnt5_x86-32_8025PE_svctest_VIA92.7z" was pulled.

Last edited by Jaak (2008-02-22 03:57:24)

The answer was 42?
Kind regards, Jaak.
  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

Hi Jaak,

jtdoom let me know on the 911cd forums about this new testpack, so I've just downloaded and will start some tests after breakfast. Thanks indeed for producing this as it is very helpful to see what is possible.

@OverFlow
Yes, one purpose of my OfflineSysPrep app is to provide injection of drivers for new/current hardware into an image or partition not having these drivers needed for successful boot. However, another purpose is to provide the option of injecting all the BartPE plugin drivers (for the particular OS) as well. I had thought this was working, but lately we've been having an ntfs.sys error occuring which may be suggestive of a memory limit being transgressed. Another possibility is some driver issue/conflict -- hopefully there might be success with the latest testpack. I'll provide feedback either way.

Regards,
Galapo.

  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

OK, I'm nearly ready to run some tests with 'DP_MassStorage_wnt5_x86-32_8024nightly.7z'. 'DP_MassStorage_wnt5_x86-32_8025PE_svctest_VIA92.7z' failed with the current injection method throwing up the 'ntfs.sys' error. Likely this is really just an issue with the task I'm putting to the pack, not the pack itself. BartPE plugin itself runs fine.

Some preliminaries on DP_MassStorage_wnt5_x86-32_8024nightly.7z:

1. Similarities remain at: m\h6 -> m\h6s; m\h7 -> m\h7s; m\h9 -> m\h9s; m\ib2 -> m\ib3. Maybe also m\n; m\p*.

2. Line 106 of iastor70.inf required correction.

3. Silicons have various "similar" files between different versions:

SilRemFil.sys v. 1.1.3.0: m\sb2, m\sb3
SilRemFil.sys v. 1.1.4.0: m\s8, m\sc3
SilRemFil.sys v. 1.1.6.0: m\s7b, m\sb4, m\sc4
SilRemFil.sys v. 1.1.7.0: m\s3, m\sb5, m\sc5

SiWinAcc.sys v. 1.0.0.11: m\s3, m\24, m\s7b, m\s7a, m\s7, m\s8, m\s8a, m\sa, m\sa2, m\sb, m\sb2, m\sb3, m\sb4, m\sb5, m\sc, m\sc2, m\sc3, m\sc4, m\sc5
SiWinAcc.sys v. 1.0.0.8: m\s9

siisupp.vxd: md5 4F53C93F9113DC7A867A268D78B7928E: m\s5, m\s7, m\s7a
siisupp.vxd: md5 1E8DD8F6C174B7A3656390E3E41D78AF: m\s4

Regards,
Galapo.

  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

OK, test results in: not good, but at least it provides more confirmation that a memory limit is being reached.

1. Injected 8025 mass storage drivers with OfflineSysPrep which added 113 new services -- ntfs.sys error.

2. Injected all 8024 mass storage drivers with peimg which added 129 new services -- nvata4in.sys error, likely due to driver similarities remaining under \m\n.

3. Injected all 8024 mass storage drivers minus \m\n with peimg which added 123 new services -- ntfs.sys error.

4. Injected all 8025 mass storage drivers minus \m\n with peimg which added 123 new services -- ntfs.sys error.

Tests confirm that the "OfflineSysPrep" method of injection may not necessarily be in error as peimg also fails. My earlier tests with peimg likely did not reach this possible memory limit due to driver similarities and so the number of services was within bounds. Ilko's and cdob's guess that some memory limit is being breached seem most likely at this stage.

Got some thinking to do...!

Thanks again for providing what was necessary to conduct these tests.

Regards,
Galapo.

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: service entry naming conventions

the error they refer to is based on previus experience we have with windows 2000...

the memory limit for 2000 was reached years ago and occasionally we breach it by accident when we add new drivers.

We have not been able to acheive this limit in XP or 2K3 (yet).

I belive (without any real proof) that the drivers do not in of themselfs (totaling thier cumulative sizes) achive the undiscovered limit.
the most likely cause of this is a corruption of RAM - IE a driver is burning more than its share or is loaded more than once.
IE a conflict that corupts RAM...

this is an easy theory to prove - remove a few dozen drivers and run a test.

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

OverFlow wrote:

the error they refer to is based on previus experience we have with windows 2000...
this is an easy theory to prove - remove a few dozen drivers and run a test.

ilko's done some "broad" tests on this:

1. Disabling all drivers fitting the following named variables 3*, a*, m*, si3* with everything else enabled results in a booting system.

2. Disabling all drivers and enabling only those fitting the following named variables 3*, a*, m*, si3* results in a booting system.

Two possibilities seem to be evident: either a memory limit being breached, or a some driver conflect somewhere in these broad "groups" of drivers.

Regards,
Galapo.

Last edited by Galapo (2008-02-20 14:50:48)

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: service entry naming conventions

divide and conquer.

split the groups in half untill the offending unit is found.

I am sticking to my conflict theory....  the memory limit is not yet attained...
you are welcome to prove me wrong wink

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

Well, my hope is still that we haven't reached a memory limit as it makes things much more difficult.

We'll see... I'm still running tests on this hoping to find the possible conflict.

Regards,
Galapo.

  • Jaak
  • Old Timer Rookie
  • Offline
  • From: Eeklo, in the East Flanders
  • Registered: 2006-07-23
  • Posts: 3,594

Re: service entry naming conventions

the vxd files are for win98/winME.
This topic is about NON-disc install.. should we not move this to other platforms?

The answer was 42?
Kind regards, Jaak.
  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

Here's the tests I did. All drivers were injected with OfflineSysPrep into an XP sp2 VMWare machine.

I am not very good at seeing patterns. But it appears to me that whatever combination of drivers chosen, you just can't do TOO many else you're hit with the ntfs.sys error. The "loader error 3" error message I had two time is interesting and I've never seen it before.

1. enabled all apart from a*, m* = ntfs.sys error = added ~81 drivers
2. enabled all apart from  a*, m*, si3* = success = added ~64 drivers
3. enabled all apart from a*, m*, i*, n* = success = added ~69 drivers
4. enabled all apart from a*, n* = nyfs.sys error = added ~87 drivers
5. enabled all apart from a*, n*, i* = ntfs.sys error = added ~81 drivers
6. enabled all apart from a*, m*, n* = ntfs.sys error = added ~75 drivers
7. enabled all apart from 3*, a*, m*, n* = success = added ~66 drivers
8. enabled all apart from 3*, m*, n* = ntfs.sys error = added ~90 drivers
9. enabled all apart from 3*, a*, n* = ntfs.sys error = added ~78 drivers
10. enabled all apart from 3*, a*, m* = success = added ~72 drivers
11. enabled all apart from a*, m*, h* = ntfs.sys error = added ~90 drivers
12. enabled all apart from 3*, a* = ntfs.sys error = added ~84 drivers
13. enabled all apart from 3*, a*, h* = ntfs.sys error = added ~78 drivers
14. enabled all apart from 3*, a*, c*, h* = success = added ~73 drivers
15. enabled all apart from 3*,a*, c* = ntfs.sys error = added ~79 drivers
16. enabled all apart from a*, c*, h* = ntfs.sys error = added ~82 drivers
17. enabled all apart from 3*, c*, h* = ntfs.sys error = added ~97 drivers
18. enabled all apart from3*, c*, h*, i* = ntfs.sys error = added ~91 drivers
19. enabled all apart from 3*, c*, h* i*, p* = ntfs.sys error = added ~87 drivers
20. enabled all apart from 3*, c*, h*, i*, p*, q* = "loader error 3" error = added ~83 drivers
21. enabled all apart from 3*, c*, h*, i*, p*, q*, r* = success = added ~80 drivers
22. enabled all apart from 3*, c*, h*, p*, q*, r* = ntfs.sys error = added ~86 drivers
23. enabled all apart from 3*, c*, f*, h*, p*, q*, r* = ntfs.sys error = added ~81 drivers
24. enabled all apart from 3*, c*, d*, f*, h*, p*, q*, r* = ntfs.sys error = added ~78 drivers
25. enabled all apart from 3*, c*, d*, f*, h*, p*, q*, r*, u* = ntfs.sys error = added ~75 drivers
26. enabled all apart from 3*, c*, d*, f*, h*, p*, q*, r*, u*, v* = success = added ~84 drivers
27. enabled all apart from c*, d*, f*, h*, p*, q*, r*, u*, v* = ntfs.sys error = added ~81 drivers
28. enabled all apart from c*, d*, f*, h*, i*, p*, q*, r*, u*, v* = success = added ~75 drivers
29. enabled all apart from c*, d*, f*, h*, i*, p*, q*, r* = "loader error 3" error = added ~81 drivers
30. enabled all apart from c*, d*, f*, h*, i*, p*, q*, r*, u* = success = added ~78 drivers

Regards,
Galapo.

Last edited by Galapo (2008-02-21 13:37:55)

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: service entry naming conventions

if you belived it was size then you could total the size of the listed *.sys files and see what the totals are for each group.

you may have to allow some slack space (each driver may occupy slightly more ram than its actual size)

if the size theory was correct it wouldnt matter which drivers where included only thier cumulative sizes.

test and report ill see what i can tell you

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

I've edited my post above with how many drivers were injected with each test. To me it seems there's some sort of limit generally in the mid 70's.

cdob's made a helpful post here: http://www.911cd.net/forums//index.php? … p;p=142720

Regards,
Galapo.

Last edited by Galapo (2008-02-21 13:41:33)

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: service entry naming conventions

the number of drivers is not as signifigant as the size - IE one driver may be 120k but others may be 360k...
you could have three more 120 in place of one 360 if it were a size limit...

link above is dead

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • Jaak
  • Old Timer Rookie
  • Offline
  • From: Eeklo, in the East Flanders
  • Registered: 2006-07-23
  • Posts: 3,594

Re: service entry naming conventions

the testfile for galapo "DP_MassStorage_wnt5_x86-32_8025PE_svctest_VIA92.7z" was pulled from FTP.
Each little mistake would make it quite flaky and the work was "iffy" at best..

SiL: I will try find the WU drivers  and hope these are BIOS independant.
That would be far better than having several sets for one type of device.

The answer was 42?
Kind regards, Jaak.
  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

Jaak wrote:

Each little mistake would make it quite flaky and the work was "iffy" at best..

I agree. But it was good of you all to make such a test available for a while. My opinion is to stick with what worked previously, ie do not go with the temporary name changes we had in 8024 and 8025.

@OverFlow
Sorry, the 911cd forums we down for a little while it seems. Link should again we working to read cdob's post.

Regards,
Galapo.

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: service entry naming conventions

cdob makes a good point about compressed vs non compressed drivers. uncompressed they may take a lot more ram.
furthermore i belive with your method the support files also get loaded. if this is true it is much different than textmode setup where they are not needed or loaded into ram. Support files are eventually loaded by PNP in PE and then we don't have the memory limit and only the files required for a needed controler are loaded instead of all of the drivers. so if there are support files with the same name it will not matter (to us at driverpacks for slipstreaming) since they are loaded only if needed on the current installation.

Somebody stomped on my username over at 911 i had to register with an alternate name sad
(and that person has a whopping 2 posts since 2005 - unfortunately they did visit as recently as last week - so it's not a dead account)

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

Yes, with this method whatever drivers get injected all get loaded. With the injection method internal to OfflineSysPrep it is only the main driver files, no secondary drivers. Full PNP after first boot is probably mandatory. Injecting with peimg is a different matter as the installation is directly via the .inf, so whatever drivers there that are references get injected and consequently loaded. With the setup routine there will be far less services running so that no memory limit is currently breached, but it seems injecting drivers into an already installed system that limit can be reached, at least under the conditions and methods I've tested here.

Regards,
Galapo.

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: service entry naming conventions

it seems to me that offline sysprep is useful for moving a drive to a new system in which case you will only need to "add" one driver and then not have a problem.

if it is your desire to create / modify an image that could be loaded onto multiple machines (the true intent of sysprep) then the better way to go would be to use a driverpacks slipstreamed source to begin with (one of the few times KTD is useful). in that way all of the mass storage drivers would always be available. (or any other drivers that were Kept by Keep The Driver (KTD).

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • From: Sydney, Australia
  • Registered: 2007-10-23
  • Posts: 175

Re: service entry naming conventions

OverFlow wrote:

it seems to me that offline sysprep is useful for moving a drive to a new system in wich case you will only need to "add" one driver and then not have a problem.

Yes, that has been my own primary aim from the beginning ... then people started suggesting adding all the drivers...

if it is your desire to create / modify an image that could be loaded onto multiple machines (the true intent of sysprep) then the better way to go would be to use a driverpacks slipstreamed source to begin with (one of the few times KTD is useful). in that way all of the mass storage drivers would always be available.

Yes, I think you are indeed correct. Other methods -- at least with xp -- will encounter the memory issue at some stage. Version 2 of OfflineSysPrep will allow for injection of user-provided driver(s) via their .inf(s) with peimg. This in addition to the option of injecting the DP driver(s). I think it will be a good way of moving a full install onto newer hardware in the case of replacing the motherboard etc. Inject the DP driver for the detected hardware, or supply driver files yourself and inject.

Regards,
Galapo.