Hi all,

I've just posted a new page on the NT4 Reference site regarding my research into
how NT4 handles Devices and Services, and manually adding or removing same.

You can read it here: http://nt4ref.zcm.com.au/mansd.htm

As always, I welcome comment, feedback, corrections etc...

Calvin.

Calvin mentioned Memtest86+
http://www.memtest.org/
and then
It's Deja Vu All Over Again .....
for i remembered in Feb. i burned
their V1.51 burned to bootable CDR

also http://hcidesign.com/memtest
for their free version runs under windoze ..
from: alt.comp.periphs.mainboard.msi-microstar
http://tinyurl.com/asphp
where HCI Design Memtest reported errors
where Memtest86 did not ..

from: http://oca.microsoft.com/en/windiag.asp
http://oca.microsoft.com/en/mtinst.exe
makes bootable floppy or bootable CD image windiag.iso
((of course i could Not remember how to make a
bootable CD so after making two coasters;
it was so simple:
Nero 5.5 File: Burn-Image; then choose windiag.iso !!!
then when booted on the CD:
Multiple tests; P to pause; M for Menu V0.4
:rod

Calvin wrote:
Great page as usual; but since you asked ..
so is following erroneous/typos documentation ?? :rod
.......................
NT 4 ResKit: WORKSTN.HLP 1996/09/04
"The data type for ImagePath must be REG_SZ
or REG_EXPAND_SZ."
ImagePath Value Entry
This value entry identifies the path and file name of the driver.
You can use My Computer or Windows NT Explorer to verify
the existence of the named file. The ImagePath for
LanmanWorkstation is %SystemRoot%\System32\Services.exe.

NT 4 ResKit: Regentry.hlp 1998/01/29
Standard Entries in the Services Subkeys
The following standard value entries appear in most subkeys
representing services in the Services subkey. The content of
the subkeys for each service vary depending on the nature
of the service, whether the service is Plug and Play, and
whether the service is installed on the computer.
Warning
This information is presented for reference only. You cannot
reliably install, remove, or change the configuration of a
service by editing the value entries in this subkey. To install,
remove, or configure a service, use Sc.exe, a tool included
on the Windows NT Resource Kit 4.0. Programs should use
the the standard Win32 APIs: CreateService API,
ChangeServiceConfig API, or DeleteService API.

Registry path:
HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\Service name

ImagePath REG_DWORD Path and filename
Device type Default value
Default: Driver Systemroot\System32\Drivers\Drivername.sys
Service Systemroot\System32\Servicename.exe
Specifies the location of the executable file for the driver or
device. This value entry is not used for network adapter cards.
Note
This information is presented for reference only. You cannot
change the path where Windows NT searches for a service's
executable file by editing this value entry. To change the
value of ImagePath, use the ChangeServiceConfig API or
Sc.exe, a tool included on the Windows NT Resource Kit 4.0.
Technical Reference to the Windows NT Registry © Microsoft
Corporation 1985 - 1997
.......................
so; 3 comments:
1) imho iirc whenever REG_EXPAND_SZ is
used in registry then REG_SZ works as
well which makes compatable with regedit.exe
(( just do Not use %var% in the string !!))
2) they seem to imply must use sc.exe; not just
edit the reistry ???
3) typo: "ImagePath REG_DWORD" ??
for dword is 32 bits; not enough for name ??

:rod

nt4-ever wrote:

I have done a lot of experimenting with the registry entries and sorting out
what can be practically done, and what 'falls over' if you try. Hence my
comments about ImagePath being in the form of \??\Drive:\Path\FileName and of
type REG_Expand_SZ - hence it being presented a string of hex in a RegEdit16
..reg file. When you import this, it is in fact a REG_Expand_SZ datatype.

In other words, they don't trust us to do it right !! You definitely can change
behaviour or remove/add a device or service using my techniques - it is just
VITALLY important you have you head screwed on right when you do this and
perform the procedure correctly !

Obviously a boo-boo by Microsoft, Your comments above about it being REG_SZ or
REG_Expand_SZ are correct.

Wrong again - this is all typical of Microsoft, a campaign of FUD to try to
scare people out of doing anything. The ImagePath CAN be changed, and I can
guarantee you (unless the driver or service has hardcoded overrides within -
this does happen sometimes) you CAN relocate a device or service and change the
ImagePath and the system will use it ! This was thoroughly tested before I
publish my article.

Reason I nominated the \??\Drive:\Path\FileName (Symbolic Link syntax) ImagePath
was because this approach appears to be the most reliable. I am certain there
are bugs in NT4 in this area.

For example, if you specify the ImagePath as datatype Reg_Expand_SZ and provide
a path in the form %SystemRoot%\System32 or %SystemRoot%\System32\Drivers NT4
will flatly refuse to load the device/service and give either a 'file not found'
or 'path not found' error.

Yet if you provide a syntax like datatype REG_SZ and give eg:
\SystemRoot\System32\FileName and the device/service will load - sometimes !
Notice the path provided is in fact illegal it is \SystemRoot\ NOT %SystemRoot%\

I have also found REG_SZ datatype and a standard full path eg:
D:\WinNT\System32\Drivers will work FAIRLY reliably.

The whole thing was erratic and unpredictable - unless you use Symbol Link
Syntax, then it works properly and consistently. I notice several
services/device added by third parties use this approach - hence where I got the
idea from - and obviously they know things we don't - because it actually works
properly :-)

They don't trust us :-)

A typo - and typical of Microsoft, they are extremely careless sometimes. One
wonders if the same level of carelessness flows over into their coding - could
explain a lot !

Calvin

Calvin said:
"The whole thing was erratic and unpredictable - " ...
"A typo - and typical of Microsoft, they are extremely careless
sometimes."

just used regedt32 to export a text file of
hklm\SYSTEM\CurrentControlSet\Services;
all "ImagePath" were REG_EXPAND_SZ
but varied eg:
%SystemRoot%\System32\services.exe
\??\C:\SYS\K6Speed\k6speed.sys
\??\C:\Winlcl\DIAGS\NT_RegMon\HANDLE.SYS
\??\C:\WINNT\System32\Drivers\EPLPDX01.SYS
\??\C:\WINNT\System32\drivers\qic117.sys
\??\C:\WINNT\System32\vsdatant.sys
\??\D:\PROGRA~1\MY_PER~1\SETK6\DirectNT.SYS
\??\D:\Temp2\TEMP4\SoftFSB.SYS
\SystemRoot\System32\drivers\afd.sys
\SystemRoot\System32\drivers\opl3sa.SYS
C:\WINNT\System32\MsiExec.exe /V
c:\winnt\system32\pstores.exe
D:\Program Files\APPS\Dklite\DKService.exe
D:\TEMP\GHMU.exe
System32\DRIVERS\atapi.sys
System32\DRIVERS\et4000.sys
System32\DRIVERS\piixide.sys

These all seemed to work;
Notice the "MsiExec.exe /V" entry !! ??

i first noticed that REG_DWORD typo on the
ms Q-KB faq for NT 3.1 ... and somehow it stayed
thru to the NT4 1998/01/29 REGENTRY.HLP

http://technet.microsoft.com/default.aspx
No Joy in FireFox 1.04 Nor InterNet Xploader (IE 5.5)
.... have they re-designed their pages for IE-7 ??
:rod

nt4-ever wrote:
My system wasn't even as clear cut as what your shows as - I have a mixture of
ImagePath entries of datatype REG_SZ and REG_Expand_SZ - obviously different
software writers tackle this in different ways, I suppose as long as the result
works, who are we to argue ?? :-)

I suspect that using Sc.exe, or the Win32 API as Microsoft mentions (which a
install package would do) may be able to get reliable results using datatype for
the ImagePath of other than Symbolic Link syntax - but as I said in my article,
the reliability using direct registry entry with datatypes other than Symbolic
Link syntax is poor.

I just tried the link in Mozilla Browser 1.7.12 - works OK here to get to the
front page of the site, I didn't go fishing into the internals however. The
Microsoft website - TechNet in particular - has always been a 'problem child'
when it comes to browsers other than IE - I often have trouble with the left
hand 'menu bar' failing - with stupid error messages like 'page not found' etc.

I know this menu bar is JScript based, and of course only IE implements JScript
(Microsoft's "if you can't beat them, prostitute the standard" creation that is
supposed to work like JavaScript) which works just sufficiently differently to
JavaScript to cause endless problems on a JavaScript based browser.

I have actually complained to Microsoft about the extremely poor performance of
their website on numerous occasions - a total exercise in futility of course,
the complaints got responded to with standard "we can't find anything wrong
here" answers !

Calvin.