AutoPatcher Forum

This is happening on a Windows 2003 Server x86/English box:

On launch, apup.exe (latest release as of this writing is 1.00.0005) produces the following errors:





After that last error, AutoPatcher Updater displays its component selection list with Windows 2000 SP4 (x86/English) and Windows 2003 SP2 (x86/English) automatically selected.



Using /log only begins to write to the log file after that last error, but here it is for those interested:

	 APUP Has Started

	 Operating System: English (1033) Windows Server 2003 R2 Standard 32-bit Service Pack 2
	 Current Locale: English - United States / Non-Unicode Default: English - United States
	 Starting APUP From: C:\Documents and Settings\Administrator\Desktop\Utilities\Autopatcher\apup
	 Date & Time: 01-Dec-2008 13:08 UTC Offset: -5

	 ***Downloading/Processing Releases.list***

	 List file HTTP location: http://www.autopatcher.com/releases.list

	 ***Releases.list Processed: Waiting for User Input***

	 Exit button has been pressed!!!

Using ProcMon, I've tried to poke around what it may be tripping on. This is what I've noticed:



Looks like AutoPatcher is having a problem with my environment settings. Not sure why, it's all a standard install. Here's my SET from a command prompt:

	 C:\Documents and Settings\Administrator>set
	 ALLUSERSPROFILE=C:\Documents and Settings\All Users
	 APPDATA=C:\Documents and Settings\Administrator\Application Data
	 ClusterLog=C:\WINDOWS\Cluster\cluster.log
	 CommonProgramFiles=C:\Program Files\Common Files
	 COMPUTERNAME=JANUS
	 ComSpec=C:\WINDOWS\system32\cmd.exe
	 DEVMGR_SHOW_DETAILS=?
	 DEVMGR_SHOW_NONPRESENT_DEVICES=1
	 FP_NO_HOST_CHECK=NO
	 HOMEDRIVE=C:
	 HOMEPATH=\Documents and Settings\Administrator
	 LOGONSERVER=\\JANUS
	 NUMBER_OF_PROCESSORS=2
	 OS=Windows_NT
	 Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
	 PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
	 PROCESSOR_ARCHITECTURE=x86
	 PROCESSOR_IDENTIFIER=x86 Family 15 Model 107 Stepping 2, AuthenticAMD
	 PROCESSOR_LEVEL=15
	 PROCESSOR_REVISION=6b02
	 ProgramFiles=C:\Program Files
	 PROMPT=$P$G
	 SESSIONNAME=Console
	 SystemDrive=C:
	 SystemRoot=C:\WINDOWS
	 TEMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp
	 TMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp
	 USERDNSDOMAIN=JANUS.NET
	 USERDOMAIN=JANUS0
	 USERNAME=Administrator
	 USERPROFILE=C:\Documents and Settings\Administrator
	 windir=C:\WINDOWS
	 _JAVA_OPTIONS=-Dsun.java2d.d3d=false

Thoughts?

Hi psouza4 and welcome to the forums.

Thank you for posting a full error report. We have had a user report the first of your error messages before, but never been able to duplicate it.

Let me "translate" the first two APUP errors

(1) the prjUpdater.mdlInitialization.initFolders dialog means APUP cannot find the system32 folder. At this point it should have found the %windir% folder and is checking that the system32 folder is actually system32.

(2) the prjUpdater.mdlEnvironmentDetection.getSystemComponents dialog means APUP cannot find a particular file in the system32 folder. At this point it is looking at file version numbers of specific files in the system32 folder in order to determine (for example) the Internet Explorer version.

Since APUP has already not been able to find system32 at (1), then error dialog (2) will be bound to occur if APUP is allowed to continue.

I can see from your %Path% environment variable that you do indeed have a standard system files layout. The next step is to determine why APUP cannot "see" this folder. I will have to consider the ProcMon results and come back to you on that, but in the meantime, given the meaning of the first two dialogs, I have a number of questions:
Do you have any special permissions set on the WINDOWS or system32 folders? Is either hidden? Is either read-only? Does the local Administrator have Full Control of those folders? Any restrictive ACLs or other form of lock-down?

--

I'm afraid that's all a dead-end, James:

C:\>cacls WINDOWS
C:\WINDOWS NT AUTHORITY\Authenticated Users:R
		   NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(special access:)
														GENERIC_READ
														GENERIC_EXECUTE

		   BUILTIN\Server Operators:C
		   BUILTIN\Server Operators:(OI)(CI)(IO)C
		   BUILTIN\Administrators:F
		   BUILTIN\Administrators:(OI)(CI)(IO)F
		   NT AUTHORITY\SYSTEM:F
		   NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
		   BUILTIN\Administrators:F
		   CREATOR OWNER:(OI)(CI)(IO)F

C:\>cacls WINDOWS\System32
C:\WINDOWS\system32 NT AUTHORITY\Authenticated Users:R
					NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(special access:)
																 GENERIC_READ
																 GENERIC_EXECUTE


					BUILTIN\Server Operators:C
					BUILTIN\Server Operators:(OI)(CI)(IO)C
					BUILTIN\Administrators:F
					BUILTIN\Administrators:(OI)(CI)(IO)F
					NT AUTHORITY\SYSTEM:F
					NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
					BUILTIN\Administrators:F
					CREATOR OWNER:(OI)(CI)(IO)F

Likewise:

C:\>attrib WINDOWS
		   C:\WINDOWS

C:\>attrib WINDOWS\System32
		   C:\WINDOWS\system32

It's a standard install from a few months ago on a freshly-formatted and partitioned drive. Nothing funky with anything else on the system. No RAID.

Note that I am logged in as the local administrator while attempting to run AutoPatcher and for all of my command prompt output. At one point during my original post, I moved the 'apup' folder from my Desktop\Utilities folder to the root of C: to see if it'd help (it didn't), so you will notice there is inconsistency with the paths in my screen shots/debug log and the paths to the AutoPatcher DLL's in the ProcMon output. The results are the same either way, though. Also of note: I neglected to capture screen shots of subsequent application pop-up errors. They have the same message as the second one, but occur on lines 104 and 108 instead.

Thank you for the welcome and for your time. Please let me know if you would like any other information; it'd be nice to roll out AutoPatcher to this system.

Let me deal with the easy part, first:-

psouza4, on Dec 1 2008, 11:40 PM, said:

I expected these two errors. That's because they are also checking for files in the system32 folder, so the cause is the same as it is for the second error.

Now for the difficult part, which is trying to solve why the system32 folder is not being found by APUP. I've been through all the information you've posted and cannot see what the problem is. However, the detection code is written in Visual Basic, which means that I can write a short piece of VBScript which does almost exactly the same thing. I have written testfldr.vbs (inside testfldr.zip) which (1) finds the WINDOWS folder, (2) finds the system32 folder two different ways and then finds the TEMP folder, all done with a few system calls the way that APUP does it.

 testfldr.zip (334bytes)
downloads: 9
Could you please try this out and report back? Once you've satisfied yourself that the code is harmless, can you please run it and confirm that you see four pop-up dialogs reporting the folder locations. The important part is the second and third pop-ups which should both give exactly the same answer.

--

I changed your msgbox's to Wscript.Echo's so that I could capture all the output at once:

C:\Documents and Settings\Administrator\Desktop>cscript testfldr.vbs
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

The path to your WINDOWS folder is [C:\WINDOWS].
The path to your System folder is [C:\WINDOWS\system32].
The made path to the System folder is [C:\WINDOWS\system32].
The path to your Temp folder is [C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp].

I don't see anything peculiar, though.
Edited by psouza4, 02 December 2008 - 11:37 PM.

What order are you getting the error messages when you start apup? Are you getting the Path Not Found error first or second?

Erik Ramey, on Dec 2 2008, 07:59 PM, said:

Yes, I am. It's the exact order posted in my first message in this thread.

Thanks for running the test.

psouza4, on Dec 2 2008, 11:28 PM, said:

That's OK -- it ran as it should do.

Now, the VBscript is working as intended, yet APUP which contains almost exactly the same code at this point in Visual Basic (using the exact same system calls) is not working. At present I don't know why. When you run ProcMon on APUP can you see APUP making calls similar to the VBScript?

--

James, on Dec 3 2008, 08:51 AM, said:

Sort of. GetSpecialFolder() isn't an actual API, so searching for its equivalent in ProcMon is tedius, at best. I do see though, where apup is attempting to read C:\WINDOWS\system32\scrrun.dll at various offsets. Apup isn't interested in reading file contents from any other file and this occurs right before apup's first error (and consequently it's attempt to access WINDOWS\System32 in the wrong path). Is it possible that you're expecting something other than the version of C:\WINDOWS\system32\scrrun.dll that I have?

scrrun.dll (no special permissions/ACLs)
Size: 151,552 bytes
Created/modified:  Sunday, February 18, 2007, 7:00:00 AM
File version: 5.6.0.8832
Description: Microsoft (r) Script Runtime
Copyright:  Copyright (C) Microsoft Corp. 2002

Here is the ProcMon log (in all available formats): apup_procmon_log.zip (244 KB)

APUP shouldn't mark 2000 initially when you run APUP. This was an unrelated tweak to the release.list file. Still unsure about the system32 directory though. Since the fs.GetSpecialFolder(1) variable is obviously working from a previous variable set but "fs.GetSpecialFolder(0) & \system32" isn't doesn't make any sense

bump -- any ideas out there?

Well, we're working on an update to Apup as present, but we have not yet come up with any more ideas as to why it is not working on your Server 2003 system.

If this was a 64-bit system, I could explain why the VBscript code runs and Apup does not (64 -v- 32-bit context).
If the error was across a network, I could explain that too (GPO problem/ bug in advapi32.dll).
But we don't have either of those.

scrrun.dll major/minor version is 5.6 -- as on working systems, so I don't think that is the problem, either.
I've not noticed anything that is obvious in the ProcMon log (although searching for system/system32 in the %HOMEPATH% folder tree does seem slightly odd). I don't know enough about 2003 to know if it has bugs with %HOMEPATH%.

Have you tried Apup.exe on any other system, to confirm that it is just Apup on Server 2003 R2 that fails?

If we can't find an answer, we will try and code our way round the problem in the next update to Apup, but that is (I guess) a week or more away.

--

I've tested it on a the same OS as being ran here with no problems. I'll I think our next step is to see what apup is using as your environment variables. I'll shoot you a customized apup.exe that will list your variables in the log. This might tell us something.

Give me a day or so to get this to you. Also make sure to answer James question too =)

It's only on this machine. I have another box (Intel CPU) that used the same Windows Server 2003 install CD that runs the same apup build without issue.

I've also run it on XP, XP x64, etc. without issue.

Thanks, Erik. Have that build handy?

.. bump ..

psouza4, on Dec 13 2008, 11:16 PM, said:

...... bumpity ......

psouza4, on Dec 17 2008, 10:46 AM, said:

Erik? I know you said to give you a day or two... it's been a month though. Would love to be able to use AutoPatcher.

Thanks!

psouza4, on Jan 6 2009, 02:14 PM, said:

I've just duplicated the problem on a Windows 2003 R2 server too. Standard build, fully patched.

Phil

PRandal, on Jan 19 2009, 03:55 PM, said:

I PMed him with no reply. It's a shame, but I think the thread's abandoned.

> I think the thread's abandoned
no, it isn't. we just are having a lot of issues and i can't promisse anything regarding time to fix something right now

[]s