Jump to content











Photo
- - - - -

cannot start tcpipreg service


  • Please log in to reply
20 replies to this topic

#1 lianzi2000

lianzi2000

    Member

  • Members
  • 43 posts
  •  
    United States

Posted 16 March 2011 - 04:49 AM

I'm playing with the latest version of win7PE_SE. It's fantastic!

The error occurs with PENetwork script. The resulted WinPE3.0 cannot support network -- penetwork.exe says "error occurred while starting 'Tcp/ip Registry Compatibility' service (2) blah blah.... ". I tried to start the service manually by typing 'net start tcpipreg' and indeed it gave the message "system error 2 occured, windows cannot find the file", yet I checked the registry and the ImagePath for this service is "System32\drivers\tcpipreg.sys", and I confirmed this file does exist under X:\Windows\System32\drivers. Googled and Binged but find nothing helpful. Anyone have had a same/similar experience? please help!

TIA

lianzi2000

#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16022 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 16 March 2011 - 04:01 PM

It sounds a lot like a "legacy" error:
http://www.modemsite...duns-tcpip2.asp

Checking the two mentioned KB may help :cheers: (or completely fail to) :whistling:

:cheers:
Wonko

#3 lianzi2000

lianzi2000

    Member

  • Members
  • 43 posts
  •  
    United States

Posted 16 March 2011 - 04:36 PM

Thanks! :whistling: I'll check tonite

:cheers:
lianzi2000

#4 ludovici

ludovici

    Silver Member

  • .script developer
  • 610 posts
  • Location:France
  •  
    France

Posted 16 March 2011 - 05:02 PM

Hello lianzi2000 :cheers:
Thanks Wonko the Sane great utility :whistling:

And in Device Manager Check "Show Hidden Device"
You will seen TCPIP Reg Service and you can maybe start manually...

#5 FerrariGuy

FerrariGuy

    Member

  • Members
  • 50 posts
  • Location:South Carolina
  •  
    United States

Posted 02 September 2011 - 09:42 PM

lianzi2000, did you ever find a resolution for this? Ever since I swiched to a non-explorer shell I'm having this problem. Searches suggest that folks sporadically have this issue when building WinPE. For me, if I make the "explorer" shell the default, the TCPIPREG service starts perfectly every time. The moment I start a different shell for the first boot item, PENetwork fails in the manner you describe.

The TCPIPREG service entry and Root Enum entry in reg-edit look fine (exactly like my live system) until I try to manually start the service. That fails and then the registry changes to reflect the failure data. The legacy object entry in device manager then changes to an object with an exclamation point.

Interestingly, ProcMon shows that services.exe is looking for an "ObjectName" Reg_SZ when trying to start the service in a non-explorer shell. When "ObjectName" is not specified, services is supposed to assume the Kernal I/O call matches the service name (for a kernel driver), thus "tcpipreg." If you actulally ADD "ObjectName" = tcpipreg and try to restart the service, the error changes to say that the dependency group cannot start, rather than it cannot find the service (correctly specified by ImagePath). Of course that could just be chasing a rabbit down the wrong hole.

One other possibly important bit of info is that the network card associated GUID should show up as a service named the same GUID under HKLM\System\CurrentControlSet\Services, but it does NOT unless Explorer is the first started shell. I can manually add the entry, but it does not allow me to start TCPIPReg. http://support.micro...b/169116/EN-US/ http://support.micro...com/kb/q165846/

Below is a reg compare with the Explore Shell vs the non-Explorer shell shows that in the non-Explorer shell: (Both shells installed, but swapping which is default)

Missing everything under HKLM\Software\Microsoft\dot3svc (Running ConfigDot3.cmd in Sys32 doesn't help).
Missing everything under HKLM\Software\Microsoft\Tcpip (adding it doesn't help manually start TCPIPReg)
Missing everything under HKLM\Software\Microsoft\Tracing\svchost_RASCHAP
Missing everything under HKLM\Software\Microsoft\Tracing\svchost_RASTLS
Missing everything under HKLM\Software\Microsoft\Wlansvc
Missing HKLM\System\CurrentControlSet\Winlogon\Notifications\Components\Dot3svc\Events=Logoff
Missing HKLM\System\CurrentControlSet\Winlogon\Notifications\Components\Wlansvc\Events=Logoff
Missing HKLM\System\CurrentControlSet\Enum\Root\LEGACY_BOWSER
Missing HKLM\System\CurrentControlSet\Enum\Root\LEGACY_MRXSMB
Missing HKLM\System\CurrentControlSet\Enum\Root\LEGACY_MRXSMB10
Missing HKLM\System\CurrentControlSet\Enum\Root\LEGACY_MRXSMB20
Missing HKLM\System\CurrentControlSet\Enum\Root\LEGACY_NETBIOS
Missing HKLM\System\CurrentControlSet\Enum\Root\LEGACY_NETBT
Missing HKLM\System\CurrentControlSet\Enum\Root\LEGACY_NETDX
Missing HKLM\System\CurrentControlSet\services\bowser\Enum
Missing HKLM\System\CurrentControlSet\services\Dhcp\Configurations\ "Options"
Missing HKLM\System\CurrentControlSet\services\Dhcp\Linkage
Missing HKLM\System\CurrentControlSet\services\Dhcp\LanmanWorkstation\Linkage\ "Bind" "Route" "Export"
Missing HKLM\System\CurrentControlSet\services\mrxsmb\Enum
Missing HKLM\System\CurrentControlSet\services\mrxsmb10\Enum
Missing HKLM\System\CurrentControlSet\services\mrxsmb20\Enum
Missing HKLM\System\CurrentControlSet\services\NetBIOS
HKLM\System\CurrentControlSet\services\NetBT\ Start=3 not 1
Missing HKLM\System\CurrentControlSet\services\NetBT\Linkage
Missing HKLM\System\CurrentControlSet\services\NetBT\Parameters\Interface\Tcpip_GUIDHERE
Missing HKLM\System\CurrentControlSet\services\NetBT\Enum
Missing HKLM\System\CurrentControlSet\services\Smb
HKLM\System\CurrentControlSet\services\Tcpip
DisplayName =@%systemRoot%\\system32\\drivers\\tcpip.sys,-10001 NOT =@%systemRoot%\\system32\tcpipcfg.dll,-50003
Missing Description =
Missing HKLM\System\CurrentControlSet\services\Tcpip\Linkage
Missing HKLM\System\CurrentControlSet\services\Tcpip\Parameters
Missing HKLM\System\CurrentControlSet\services\Tcpip\ServiceProvider
Missing HKLM\System\CurrentControlSet\services\Tcpip6\
HKLM\System\CurrentControlSet\services\tdx
DisplayName ="tdx" NOT =@%systemroot%\\system32\tcpipcfg.dll,-50004
ImagePath = different
DependOnService=different
Missing HKLM\System\CurrentControlSet\services\tdx\Enum
Missing HKLM\System\CurrentControlSet\services\Winsock
Some changes to HKLM\System\CurrentControlSet\services\Winsock2 (most of it missing)
Missing HKLM\System\CurrentControlSet\services\WLansvc\Parameters\HostedNetworkSettings
Missing HKLM\System\CurrentControlSet\services\WLansvc\Parameters\WlanAPIPermissions
Missing HKLM\System\CurrentControlSet\services\{GUIDCORRESPONDINGTONETWORKCARD}

There were other hex changes & various bits that looked inconsequential boot-time generated differences. I'm sure some of the above creates when PENetwork causes network initialization. I'm just documenting some of these things so I can go back, add certain keys manually, then perhaps incorperate them into a script to see if I can make this problem less likely to happen.

#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16022 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 September 2011 - 02:08 PM

NETBIOS and SMB should be UNrelated. :dubbio:


Would a:
netsh int ip reset [ log_file_name ]

http://support.micro...kb/299357/en-us

Help? :unsure:

:cheers:
Wonko

#7 FerrariGuy

FerrariGuy

    Member

  • Members
  • 50 posts
  • Location:South Carolina
  •  
    United States

Posted 03 September 2011 - 10:56 PM

NETBIOS and SMB should be UNrelated. :dubbio:


Would a:

netsh int ip reset [ log_file_name ]

http://support.micro...kb/299357/en-us

Help? :unsure:

:cheers:
Wonko



It was worth a shot. I had to add "ifmon.dll" to system32 to get the command to work, which then reported "There's no user specified settings to be reset."

This, by the way, after I rebuilt the PE with a script that forced just about all of the above registry entries to be included. Trying to start TCPIPREG with those entries gets a respose of "The Dependency Group Failed To Start"... still missing something here... I even re-extracted my source wim files. Again, both Explorer and the non-Explorer shell (doesn't matter which one) are included, but it's only when starting the non-Explorer shell FIRST that this occurs. It doesn't make any sense, but it is repeatable in my build. I've also interactivly swapped in and out any of my custom scripts, and so far, none of them have made a difference.

--- Other post that reference this same problem:

http://reboot.pro/14255/ -->Blames Power Shell
http://www.911cd.net...showtopic=21487
http://www.911cd.net...showtopic=23609

--- Continues to hammer at this...

One possible factor is that I'm testing my builds in VMWare Workstation 7x with a virtual Intel 100/Pro MT NIC. With the non-Explorer shell, the NIC associated GUID is still not appearing in the services registry key. I might be able to reinstall the NIC, but this PE is meant to be handed to some one for a particular use. Everything has to got to be automatic.

If I can get this working I'll post my new shell script for "Emerge Desktop." http://emergedesktop.org/ I'm using it because I can more easily hide some of the items that would make PE easy to use to view the contents of any computer it is booted on. (This PE is going to someone who is a bit too nosey, but needs to do a specific task in secured conditions that cannot possibly experience an infection of any sort.)

Edited by FerrariGuy, 03 September 2011 - 10:59 PM.


#8 FerrariGuy

FerrariGuy

    Member

  • Members
  • 50 posts
  • Location:South Carolina
  •  
    United States

Posted 04 September 2011 - 03:31 PM

FerrariGuy, Are you calling wpeinit.exe before PENetwork?


Good point. Although PENetwork is called by the runonce key, I'm not sure that winpeint executed fully/properly. (Yes, PENetwork *should* be executing after Winpeint..) I'll look at the log in a few hours here and report back.

~FerrariGuy

#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16022 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 September 2011 - 04:20 PM

This, by the way, after I rebuilt the PE with a script that forced just about all of the above registry entries to be included. Trying to start TCPIPREG with those entries gets a respose of "The Dependency Group Failed To Start"... still missing something here...


This is not as "bad" news as you seem to imply.
Though AFAIK the only dependency is TCPIP.

The PENETCFG is supposed to be WinPE 2.0 compatible, so there should be not that much difference on WINPE 3.x.
http://www.911cd.net...showtopic=19443

Last version I can find is said to be working on PE 3.0 also:
http://web.archive.o...ierremounir/#PE Network Configurator

According to the documentation the only things needed are an export and re-import of two things:

IMPORTANT:
For PENetCfg to work properly under Windows PE 2/3, you have to add the "TCP/IP Registry Compatibility" service (tcpipreg) to your Windows PE 2/3 build.

Here are the steps:

1- From a working Windows Vista/7 machine:
- Copy %SystemRoot%\system32\drivers\tcpipreg.sys to the corresponding folder under your Windows PE 2/3 build.

2- Export the following Registry keys (include subkeys) and import them into your build's Registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpipreg]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_TCPIPREG]


:cheers:
Wonko

#10 FerrariGuy

FerrariGuy

    Member

  • Members
  • 50 posts
  • Location:South Carolina
  •  
    United States

Posted 04 September 2011 - 05:35 PM

Thanks Wonko. Unfortunately I've checked those registry entries over and over and over again. TCPIPREG.sys is exactly where it should be. Changing it's location & changing the reference to it in the services key does nothing. TCPIP is already started, so that's not the problem, and again, everything works just fine when the Explorer shell is started first (which I find inexplicable) unless Explorer is doing some sort of checks & fixing something. It doesn't explain why, when switching from the cmd shell (if it starts first) over to Explorer, it doesn't fix things though. I have no doubt it's compatible, but something is amiss here and I wonder if there's a common problem causing this that ties together the various forum post I referenced. I also wonder if there are some SP1 changes to TCPIPREG.sys that play into this here as well. Haven't checked that log yet...

#11 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16022 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 September 2011 - 06:03 PM

Thanks Wonko. Unfortunately I've checked those registry entries over and over and over again. TCPIPREG.sys is exactly where it should be. Changing it's location & changing the reference to it in the services key does nothing. TCPIP is already started, so that's not the problem, and again, everything works just fine when the Explorer shell is started first (which I find inexplicable) unless Explorer is doing some sort of checks & fixing something. It doesn't explain why, when switching from the cmd shell (if it starts first) over to Explorer, it doesn't fix things though. I have no doubt it's compatible, but something is amiss here and I wonder if there's a common problem causing this that ties together the various forum post I referenced. I also wonder if there are some SP1 changes to TCPIPREG.sys that play into this here as well. Haven't checked that log yet...


But the original tool was intended for "default" WINPE (the one from MS) which AFAIK has NOT Explorer as shell (but rather cmd.exe).
It seems like it is the "combined effect" of the thingy with win7PE_SE, as it is win7PE-SE that somehow requres Explorer as shell. :dubbio:

Can you try another builder/pe (just to check if this is the case)?

If I were you I would try a "default" WINPE as this one:
http://www.computerh...ic,87312.0.html
And see if in it the penetcfg works.

Or could it be related to your "non-explorer" shell?
Which shell is it (if it's no a trade secret, of course)

:cheers:
Wonko

#12 FerrariGuy

FerrariGuy

    Member

  • Members
  • 50 posts
  • Location:South Carolina
  •  
    United States

Posted 05 September 2011 - 12:04 AM

Ok, there is no winpeinit log because it never gets called by StartNet.cmd: http://reboot.pro/3033/ Launching it manually results in an instant BSOD. I have neither "Autorun HWPnP driver install" nor "Autorun Winpeint" checked in the HwPnP script. PnP initilaization begins, however, before winpeshl.ini is detected per the winpeshl.log:


Windows PE Shell beginning execution

Beginning PnP initialization

winpeshl.ini detected

Succeeded launching (null) [cdusb.exe]

Succeeded launching (null) [hide /noconsole /silent /wait x:\windows\system32\WBEM\REgisterWMI.cmd

PNP initialization succeeded.

PNP Initialization thread terminating

Succeeded launching (null) [hide /NOCONSOLE /SILENT /WAIT start.cmd]

Succeeded launching (null) [Shorcuts.exe -f x:\windows\system32\Win7PE.cfg]

Succeeded launching (null) [PinTool.exe -debug x:\windows\system32\Win7PE.cfg]

Succeeded launching (null) [X:\Program Files\PEShell\PEShell.exe]


In answer to your shell question, I've tried several: BB4WIN, uExplorer, CMD shell, and the one I'm working on, "Emerge Desktop" (using the portable version).

HWPnP runs from the runonce key, (well after winpeinit) so I'm not sure what's causing the "Beginning PnP" initilization in the WinPEShl.log unless WinPEShl also handles some PnP somehow, but it appears that it isn't supposed to call startnet.cmd unless nothing is specified in winpeshl.ini:

http://technet.micro...977(WS.10).aspx
Winlogon.exe runs setup based on the registry value HKLM\SYSTEM\Setup\CmdLine. Winpeshl.exe will launch %SYSTEMDRIVE%\sources\setup.exe if it exists, otherwise it looks for an application specified in %SYSTEMROOT%\system32\winpeshl.ini. If no application is specified, Winpeshl.exe will execute cmd /k %SYSTEMROOT%\system32\startnet.cmd. By default, Windows PE contains a Startnet.cmd file which will launch Wpeinit.exe. Wpeinit.exe loads network resources and coordinates with networking components like DHCP.

And, again, there's no winpeinit.log: http://technet.micro...941(WS.10).aspx (On X or C drive)
Wpeinit replaces the initialization function previously supported in Factory.exe -winpe. Wpeinit outputs a log messages to c:\Windows\system32\wpeinit.log.


There's nothing in the Explorer shell script that's different or autoruns just because it's first (as far as I can tell.)

I think building a base copy is a good idea. And I may just need to replicate this at home with my personal Win7SP1 Ultimate copies vs my work SP1 Enterprise copies.

#13 FerrariGuy

FerrariGuy

    Member

  • Members
  • 50 posts
  • Location:South Carolina
  •  
    United States

Posted 05 September 2011 - 02:10 AM

By running "Control" and then looking at my adapter, I discovered that no protocols or services were binding to it. I removed my network helper script (that forcibly added the missing network entries) and my com port installer script (earlier adding or removing it didn't seem to make a difference.) On a hunch I then added the line "netcfg -winpe" as the second line in the dotnet3svc.cmd batch (which installs TCP/IP, NetBios, and MS Client in the PE environment) and at least on this boot, TCPIPREG started by itself (after PENetwork tried to start & failed from the runonce key, but started fine manually.) It initially seems that netcfg -winpe was able to fix/force binding tcpip to the network adapter, which then allowed TCPIPREG to find it/work? Still a few mysteries here...

Last line below added... code at around line 240 in V12 of Holger Kotsch's PENetwork script....

If,NOT,ExistFile,%TargetDir%\Windows\system32\start.cmd,FileCreateBlank,%TargetDir%\Windows\system32\start.cmd

TXTAddLine,%TargetDir%\Windows\system32\start.cmd,start#$s/min#$sconfigdot3svc.cmd,PREPEND

ExtractFile,%ScriptFile%,configdot3svc,configdot3svc.cmd,%TargetDir%\Windows\system32\

TXTAddLine,%TargetDir%\Windows\System32\configdot3svc.cmd,netcfg -winpe,PLACE,2


...whoops on the misspelling.. wpeinit... and thanks for the explanation of why startnet.cmd is ignored in the WIn7PE projects.

]Why the Explorer shell works is still a mystery, unless, again, it interacts in some undocumented way with the network settings IF it is started at the right time?

There's still a high probability that there's something unique about the WAY I'm building this project that's causing the problem.

Edited by FerrariGuy, 05 September 2011 - 02:12 AM.


#14 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16022 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 September 2011 - 09:54 AM

Isn't this what we are revolving around? :unsure:
http://reboot.pro/3033/
Read this also (just in case):
http://reboot.pro/15311/page__st__33

@FerrariGuy
Can you post the contents of your winpeshl.ini and startnet.cmd and any description of whatever is in them?
What is "start.cmd"? :unsure:

allanf :worship: posted quite a few senceful notes :fine:, and it's very probable that it is your particular build that somehow creates the mess, as seen from the outside you probably have too many tweaks/changes whatever coming from different sources/projects/approaches and one of them is conflictiong with another, as said starting from a "less customized build may provide the needed insight, I fear :ph34r: that troubleshooting the issue form the top down (as opposed to "from the ground up") is going to be very difficult. :dubbio:

:cheers:
Wonko

#15 FerrariGuy

FerrariGuy

    Member

  • Members
  • 50 posts
  • Location:South Carolina
  •  
    United States

Posted 05 September 2011 - 07:32 PM

I think you're right Wonko, that I need to try a more *clean* build of the project and see what happens. I have interchanged all of my custom scripts out one by one to no avail, but it's probably best to just start a from-scratch default project.

PENetwork, however, is now working in this build and I have at least a theory as to why. I'm not sure this is 100% clean yet (i.e. I think I may still have some driver problems) but TCPIPREG starts as long as netcfg -winpe was called in configdot3svc.cmd. The funny thing is that PENetcfg cannot start TCPIPREG using the default PENetwork script. The service starts manually just fine. The situation is that PENetwork isn't calling an exe that can start TCPIPREG. STARTNET.EXE is included in the PENetwork folder but it's really looking for NET.exe. As soon as I include it in the PENetwork folder, PENetwork.exe can start TCPIPREG.

My theory is that Using Explorer as the shell allows the %Path% environmental variable to be properly read/used so that NET.exe can be found in System32.

In answer to your question:

winpeshl.ini:

Cdusb.exe

"hide /noconsole /silent /wait %Systemdrive%\Windows\System32\WBEM\REgisterWMI.cmd"

"cscript.exe %SystemDrive%\Windows\System32\ModifyPENetwork_INI.vbs"

"hide /NOCONSOLE /SILENT/ WAIT start.cmd"

"shortcuts.exe -f %systemdrive%\windows\System32\Win7PE.cfg"

"PinTool.exe -debug %systemdrives%\Windows\System32\Win7PE.cfg"

"X:\Program Files\PEShell\PEShell.exe"


Line 2 & 3 are added, everything else is standard.
Line 2 registers WMI. In tests, removing it seemed to make no difference to the startablity of TCPIPReg
Line 3 is a VBS that sets the computer name in the registry based on what's documented here at Reboot.pro and then rebuilds WMI and re-calls RegisterWMI.cmd.
I need to shift it up a line so that wmi does not have to be rebuilt. Again, in tests, removing it seemed to make no difference to the startablity of TCPIPReg.

START.CMD:

start /min configdot3svc.cmd


configdot3svc.cmd:

netcfg -e -c -p -i MS_NDISUIO

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinPE" /t REG_DWORD /v SkipwaitForNetwork /d 1 /f

netcfg -winpe

exit


netcfg -winpe is the new non-default item here. It installs TCPIP, and NetBios & binds them to the installed adapter.

startnet.cmd (unused by default):

winpeint


Thanks for the links, I'll check them out as soon as I get a chance.

Edited by FerrariGuy, 05 September 2011 - 07:36 PM.


#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16022 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 September 2011 - 07:12 AM

My theory is that Using Explorer as the shell allows the %Path% environmental variable to be properly read/used so that NET.exe can be found in System32.


It is very possible. :)

Add in configdot3svc.cmd a line:
SET PATH&PAUSE
before netcfg -winpe
and you can check this, though that would be the environmental varaiable (that should be set) and it is possible that Startnet.exe has *another* way to look for net.exe.

Maybe you can add a "manifest" file?

:cheers:
Wonko

#17 FerrariGuy

FerrariGuy

    Member

  • Members
  • 50 posts
  • Location:South Carolina
  •  
    United States

Posted 06 September 2011 - 02:28 PM

I'll add "Set PATH&PAUSE" to configdot3svc.cmd to double check path, but I think I'm going to see the same thing I'm seeing in the picture below:

Path is set at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment and Echos out just fine. It appears, however, that CMD doesn't know how to use those environmental variables as illustrated in the ProcMon screenshot below.

While in system32 I try to run "regedit" which is in windows or %systemroot%. We can see that %systemroot% is in %Path% and that %systemroot% is defined as X:\Windows, but CMD just iterates through the %path% options apparently not translating them or finding regedit.

Posted Image
Uploaded with ImageShack.us

I think this is diverging into a seperate problem from the initial TCPIPReg problem though.

Re: The manifest file. You're suggesting trying out an unattend.xml with wpeinit or pecmd? It's an intersting idea. I just wish Winbuilder had built in XML parsing/node editing. Hopefully it'll get there.

#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16022 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 September 2011 - 02:53 PM

Re: The manifest file. You're suggesting trying out an unattend.xml with wpeinit or pecmd? It's an intersting idea. I just wish Winbuilder had built in XML parsing/node editing. Hopefully it'll get there.

No, I am suggesting something I really know very little about :ph34r: but that in theory should be a way (together with .local) to tell apps where to find needed libraries, and what not.
http://reboot.pro/3839/

I was guessing that if net.exe is somehow called through a path that is not the actual %PATH%, maybe the behaviour of STARTNET.EXE can be modified.

BTW, are we talking of this STARTNET.EXE?:
http://www.msfn.org/...ain-your-winpe/

:cheers:
Wonko

#19 FerrariGuy

FerrariGuy

    Member

  • Members
  • 50 posts
  • Location:South Carolina
  •  
    United States

Posted 06 September 2011 - 04:30 PM

No, I am suggesting something I really know very little about :ph34r: but that in theory should be a way (together with .local) to tell apps where to find needed libraries, and what not.
http://reboot.pro/3839/

I was guessing that if net.exe is somehow called through a path that is not the actual %PATH%, maybe the behaviour of STARTNET.EXE can be modified.

BTW, are we talking of this STARTNET.EXE?:
http://www.msfn.org/...ain-your-winpe/

:cheers:
Wonko



#1. Found a signifigant bug.... Maybe a bug in WinPE7_SE... not sure... All this headache over Net/Path etc... it's because PATH is being written to the registry (at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment) as a REG_SZ not a REG_EXPAND_SZ. CMD simply cannot read and interpret %path% if it is a REG_SZ and changing it AFTER boot does no good. I can't find where it is being written in the standard WinPE7_SE scripts. It looks there's an old reference to "Session Manager" in Shell & Config, but I can't find it otherwise. I tried fixing it at that location in Shell & Config but it still ended up being a Reg_SZ so I fixed it in a custom script way down at the end of the "Components" section...



hive_load,HKLM

reg_del,"%reg%\ControlSet001\Control\Session Manager\Environment","Path"

reg_add,0x2,"%reg%\ControlSet001\Control\Session Manager\Environment","Path","%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\"

hive_unload


2. Startnet.exe... Not 100% sure it's the same but I think so. It's a 34K exe that gets unpacked as a part of the PENetwork script. I don't know what it actually does as the source is not included, but if it's the same as the link you provided this is the code:


Opt("WinTitleMatchMode", 2)

Run("X:\winpeinit.exe","",@SW_SHOW)

WinSetState("startnet.cmd", "", @SW_HIDE)


3. Re the link about the .local file. Interesting.. I've noticed ProcMon showing executed files that look like theyr'e trying to do somethign similar... like say net.exe showing up as net.exe.foo where foo is the thing it's trying to call in the same folder... then I see it call it from the right location later.. I suspect that some looking in the local folder for files is already a default behavior.

#20 FerrariGuy

FerrariGuy

    Member

  • Members
  • 50 posts
  • Location:South Carolina
  •  
    United States

Posted 06 September 2011 - 05:44 PM

RoyM was right: http://reboot.pro/14255/ It's the powershell script. http://reboot.pro/14...__fromsearch__1

*sigh* All that sitting under my nose....

#21 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16022 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 September 2011 - 06:36 PM

3. Re the link about the .local file. Interesting.. I've noticed ProcMon showing executed files that look like theyr'e trying to do somethign similar... like say net.exe showing up as net.exe.foo where foo is the thing it's trying to call in the same folder... then I see it call it from the right location later.. I suspect that some looking in the local folder for files is already a default behavior.

Yep, this is how normally apps behave, the key is this sentence:

This will instruct Windows to search for all libraries at current folder first, even if application is trying to load library using hardcoded path.

It is perfectly possible that instead of looking for "foo.dll" an app looks for (say) "%SystemRoot%\System32\foo.dll" or for :w00t: "C:\Program Files\A stupid software house\a stupid product name\foo.dll".
In the first case the local folder is preferred over the %PATH%, but in the second cases you need the .local thingy.

Happy that the problem was found and hopefully solved. :)

:cheers:
Wonko




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users