V-6.1.0.31 Bug, The array is fixed or temporarily locked

[eewiz]

XP 64-bit, my fresh install VM copy.
Ran the old APUP which downloaded the new, all combined, AP v-6.1.0.31.
I checked 20 of the 21 items to update, I don't want Vista, and got this error dialog.

The array is fixed or temporarily locked
In prjUpdater.mdlDownloader.processDownloadQueue At Line 380
The status bar at the bottom of the window said 40 items remaining.

I also got an error dialog after clicking the reboot button.
I had to reboot the box by hand.
I will give you more info on the reboot issue in my next post.

[TheAPGuy]

In prjUpdater.mdlDownloader.processDownloadQueue At Line 380
What? That is the line that ReDim an array to 0. That can't be "locked" since we are not running multi-threaded. The array is also NOT fixed. hmm... will poke around... NOPE neither of those are true.

hmm.. reboot failed? Well it simply outputs to a shell command "shutdown.exe -r -t 05" Try it yourself to see if it works. <-- will reboot you.

You and your issues vex me sir. I enjoy it. BRING IT ON!

[eewiz]

I should clarify somewhat.
The array locked issue happened toward the end of the "Download Updates" selection. The left hand button in the new 6.1 application.
More on that later.

The reboot issue happened at the end of the "Install Updates" selection. The right hand button in the new 6.1 application.
Upon returning to the issue I noticed that the C:\#AutoPatcher_Temp# folder still existed.
I moved to fast last time to record the reboot button failure error message, so here it is now.
Where: frmMain.cmdRebootNow_Click()
Error code: 0x35: File not found

I get a similar error if I wait for AP to time-out.
Where: frmMain.tmrRebootProgress_Timer()
Error code: 0x35: File not found

My VM box does have the C:\WINDOWS\system32\shutdown.exe file in place and it does shutdown from a command prompt opened on my C:\AutoPatcher folder if I enter "shutdown.exe -r -t 05".
My path does include C:\WINDOWS\system32 hence, "shutdown.exe -r -t 05" from my C:\AutoPatcher folder does work.

I have tried both, the time-out and the reboot button method multiple times. Each time, either way, I get the "File not found" error messages above.
I will also try it on my main work XP64 box but, that happens to be the box that I am posting this message on, so I will post those results in a future post.

[eewiz]

Well... Now I have tried the "Install Updates" selection on my main work XP64 box and get the exact same results.
Both reboot types report the same errors reported above for the fresh install XP64 VM box.
Here is the log from a failed reboot run.
Autopatcher v6.1.32 Has Started at 9/7/2015 1:21:13 AM

Starting Autopatcher From C:\AutoPatcher

Detected OS: Windows Server 2003 Standard 32-bit Service Pack 2
Current Locale: English / Non-Unicode Default: English
Deleting File C:\#AutoPatcher_Temp#\acrobat_reader_en_US.rti
Deleting File C:\#AutoPatcher_Temp#\admintools.rtiz
Deleting File C:\#AutoPatcher_Temp#\adobe_air.rti
Deleting File C:\#AutoPatcher_Temp#\adobe_reader_EN-US.rti
Deleting File C:\#AutoPatcher_Temp#\apengine.rtiz
Deleting File C:\#AutoPatcher_Temp#\common.rti
Deleting File C:\#AutoPatcher_Temp#\directx.rti
Deleting File C:\#AutoPatcher_Temp#\dotnet_x64.rtiz
Deleting File C:\#AutoPatcher_Temp#\dotnet_x86.rtiz
Deleting File C:\#AutoPatcher_Temp#\eight_1_x64.rtiz
Deleting File C:\#AutoPatcher_Temp#\eight_1_x86.rtiz
Deleting File C:\#AutoPatcher_Temp#\extras.rti
Deleting File C:\#AutoPatcher_Temp#\Java_jre_8_x64.rti
Deleting File C:\#AutoPatcher_Temp#\Java_jre_8_x86.rti
Deleting File C:\#AutoPatcher_Temp#\Java_jre_x64.rti
Deleting File C:\#AutoPatcher_Temp#\Java_jre_x86.rti
Deleting File C:\#AutoPatcher_Temp#\msredist.rti
Deleting File C:\#AutoPatcher_Temp#\mssecurity_enu.rti
Deleting File C:\#AutoPatcher_Temp#\offaddon.rtiz
Deleting File C:\#AutoPatcher_Temp#\office2003_enu.rtiz
Deleting File C:\#AutoPatcher_Temp#\officesp2007.rti
Deleting File C:\#AutoPatcher_Temp#\office_2007_glb.rtiz
Deleting File C:\#AutoPatcher_Temp#\office_xp_enu.rti
Deleting File C:\#AutoPatcher_Temp#\seven_x64_sp1.rtiz
Deleting File C:\#AutoPatcher_Temp#\seven_x86_sp1.rtiz
Deleting File C:\#AutoPatcher_Temp#\windows_tweaks.rti
Deleting File C:\#AutoPatcher_Temp#\xp_sp3_enu.rtiz
Deleting File C:\#AutoPatcher_Temp#\xp_x64_sp2.rtiz
Module 'Text Search in Visio Files' (unique id: 'MSVISIO_ENU_IFILTER') reports 'MSVISIO_ENU_PARENT' as its parent, but such module does not exist or is not loaded in the right order.
Module '20 Sample Diagrams for Visio' (unique id: 'MSVISIO_ENU_VIS03TEMP') reports 'MSVISIO_ENU_PARENT' as its parent, but such module does not exist or is not loaded in the right order.
Module 'Security Update for Microsoft .NET Framework 4 on XP, Server 2003, Vista, Server 2008, Windows 7, and Server 2008 R2 (KB2894842)' (unique id: 'NDP40-KB2894842-x64') reports 'DOTNET4_PARENT' as its parent, but such module does not exist or is not loaded in the right order.
Module 'Update for Revoked Certificates - March 2015 (KB3050995)' (unique id: 'KB3050995_WIN_ALL') reports 'WINDOWS_COMMON_PARENT' as its parent, but such module does not exist or is not loaded in the right order.
Installing Security Update for Windows Server 2003 x64 Edition (KB3067903)
Installing Security Update for Windows XP x64 Edition (KB3068368)
Silent Error: Attempted to give prgTotalProgress a negative value or a value too high :100

I appear to have 2 XP64 critical updates that won't install on this, my main work XP64 box but, I am not concerned with that at the moment.
Also, did you notice that the log says: "Detected OS: Windows Server 2003 Standard 32-bit Service Pack 2" when it's XP64 SP2.
I will now turn my attention to the array locked issue.
I will post again soon.

[TheAPGuy]

hmm... Is your install completely clean? Are you using a slipstreamed disk?

"Detected OS: Windows Server 2003 Standard 32-bit Service Pack 2"
This is the same core as the one in XP x64. First thing the program does is ask WMI for you system Version. Then going off that it pulls up the function responsible for that version to do more "in depth probing". Basically we ask the system product type and Suit ID. Suite ID is mostly useless now however and will be removed in the future since it has NO bearing on how detection is run. It just adds more detail to the report by adding appropriate types at the end of the OS type such as "Compute Cluster", "Small Business Server", "Storage", "Datacenter", and "Web" there are about 15 or so different suit types. Removing the sub functions for suit detection would remove a ton of lines that are mostly not used anymore since no one eve seems to have the sub types other then general installs.
Anyways just before the suit detection it will ask WMI what the product type is. It will report one of 3 things, Workstation, Domain, or Server. If it says workstation then it is XP x64 If it says Server or Domain it is 2003 Sever

I will look into why restart is failing. I suspect it is not creating the batch file and yet still calling it.

[eewiz]

All in all, your code must be getting it right in the end, as it does propose updates only for:
Windows Server 2003 x64 Edition, and
Windows XP x64 Edition.

I was not questioning the "Windows Server 2003 Standard: part of the Detected OS string. I know that XP64 is made from the 64-bit 2003 server kernel combined with a 64-bit version of explorer.exe.
I was surprised when I read the "32-bit" part of the Detected OS string.

P.S.
Now that I have run the new AP v6.1 several times, I have not seen the "The array is fixed or temporarily locked" issue again on either box.
It only happened once on my fresh install XP64 VM box the very first time I ran the v6.1 app.
Cosmic rays, maybe?

[TheAPGuy]

lol ohh snap I missed the 32bit part. Hmm since that is also gained from WMI I am going to chalk that up to some VM voodoo. What you can do is some powershell script to check the answers...

Code: Select all

$whiterabbitobject= Get-WmiObject -Class Win32_OperatingSystem

"System : {0}" -f $whiterabbitobject.OsName

"OS Type: {0}" -f $whiterabbitobject.OSArchitecture

"OS Version: {0}" -f $whiterabbitobject.Version

"Product Type: {0}" -f $whiterabbitobject.ProductType

[eewiz]

50% of the answers is a flunking grade.
I have PS 1.0 on the fresh install XP64 VM and PS 2.0 on my XP64 work box. They both report the same. I ran get-host then your script and here are the results.
I removed all data except for the version number from the get-host command.
VM:
PS C:\WINDOWS\system32\windowspowershell\v1.0> get-host
Version : 1.0.0.0

PS C:\WINDOWS\system32\windowspowershell\v1.0> machine
System :
OS Type:
OS Version: 5.2.3790
Product Type: 1

Work Box:
PS C:\Documents and Settings\eewiz> get-host
Version : 2.0

PS C:\Documents and Settings\eewiz> machine
System :
OS Type:
OS Version: 5.2.3790
Product Type: 1
PS C:\Documents and Settings\eewiz>

The results were also the same when I ran the 32-bit versions of PS 1.0 and PS 2.0 on their respective boxes.
In all cases, System: and OS Type: are blank.

NEXT ITEM
"VERY IMPORTANT"
The above may very well be the reason for this next item I have to discuss.
When "Options | General | Show Hidden Items" is selected, the following XP64 critical updates appear in gray text.
KB2862152, IPsec; KB2868626, XML Digital Signatures; KB2875783, Kernel Memory; KB2876331, GDI; KB2933528, Password Security; KB3068404, VBScript.
They were not visible in "Hidden Mode". They were all described as "Incompatible Operating System".
These updates are definitely NOT incompatible with the XP64 system.

Looking into the .APM files for these updates shows that all of them have:
[OperatingSystem]
WindowsVersion=XP_X64

All of the other .AMP files have:
[OperatingSystem]
WindowsVersion=XP_X64,2K3_X64

So, the only updates that are not hidden are those that list "WindowsVersion=XP_X64,2K3_X64". All updates that list only "WindowsVersion=XP_X64" are hidden when they should not be.

NEXT ITEM
When "Options | General | Show Hidden Items" is selected then exit AP. The next start of AP has "Options | General | Show Hidden Items" unselected yet the hidden items are shown.
Once "Options | General | Show Hidden Items" is selected it can never thereafter be unselected from the GUI.
In the .INI file, I found "ShowHidden=True". Changing it to "ShowHidden=1" doesn't help either. Neither causes the "Show Hidden Items" GUI checkbox to be checked.
Although, both do cause the hidden items to appear.
So, the end result is that once someone selects "Options | General | Show Hidden Items", they will never thereafter be able to get rid of it.
Every time they restart AP, the GUI checkbox will be unchecked and no amount of checking or unchecking it will change the .INI back to "ShowHidden=False".
Once they turn on hidden stuff they will not be able to get rid of it without editing the .INI file.

NEXT ITEM
When "Options | General | Remember Selections" is selected, my 20 selections are remembered but, the "Selection Count" is 0. If I unselect and then reselect one of the 20 items that I have selected, the "Selection Count" goes to 1.
Of course, this is minor, but it should reflect the correct number of remembered selections. I noticed this because I referred to the "Selection Count" to verify that I had not inadvertently unselected one or more of my standard 20 selected items, since I knew I did have the "Options | General | Remember Selections" checkbox selected.

NEXT ITEM
On my fresh install VM, unhidden items do show in gray text. On my work machine, those same items appear in black text and cannot be distinguished from uninstalled items.
Apparently, there is something that one can do to the UI on a box that overrides your ability to display in gray.

All for now.

[TheAPGuy]

This script right here is everything that Autopatcher will ask WMI. NOTE: This script uses a different processor check for x86/x64 and is the proper way to check via WMI (there is a registry key I can look at that is valid all the way back to Windows ME). The first script was incorrect as OSArchitecture is not available on anything less then Vista.

Code: Select all

$whiterabbitobject= Get-WmiObject -Class Win32_OperatingSystem

"System : {0}" -f $whiterabbitobject.Caption

"OS Language: {0}" -f $whiterabbitobject.Locale

"OS Version: {0}" -f $whiterabbitobject.Version

"OS Service Pack: {0}" -f $whiterabbitobject.ServicePackMajorVersion

"Product Type: {0}" -f $whiterabbitobject.ProductType



$whiterabbitobject= Get-WmiObject -Class Win32_Processor

"OS Type x86/x64: {0}" -f $whiterabbitobject.AddressWidth

The above code gives me
System : Microsoft Windows 7 Ultimate
OS Language: 0409
OS Version: 6.1.7601
OS Service Pack: 1
Product Type: 1
OS Type x86/x64: 64

If you still get some blanks here, there is not much I can help you with as it may be a VM issue. I stopped supporting and disabled the NON-WMI detection a few versions back due to it being a huge abomination and needing several API calls which may fail depending on OS. XP's were prissy about the calls and worked 70% of the time from one computer to the next. Vista and up were fine however, Microsoft pretty much said don't do this stuff anymore because we may drop those API at any moment. SO making the detection future friendly was needed. I could put in a force OS type commandline or an advanced option with a list. MS updates will not install if it doesn't detect the proper OS, so trying to install the wrong thing "should" not cause issues.

Next Item:
Yes, if it detected your OS wrongly it would hide items that are valid for you.

Next item:
ohh nice catch. Will fix that. FIXED Now reloads your list like it was supposed to instead of you needing to restart.

Next Item:
Will look into it.

Next Item:
Hmm.. strange. I mark items gray by using this line "ForeColor = vb3DDKShadow". A quick search results in no hits for problems using that technique. There might be a bug in the program. Will look at it later.

No updates to post until I get some more codding done.

[eewiz]

With your new script I now get the following on both the VM and the real box.
PS C:\Documents and Settings\eewiz> .\machine
System : Microsoft(R) Windows(R) XP Professional x64 Edition
OS Language: 0409
OS Version: 5.2.3790
OS Service Pack: 2
Product Type: 1
OS Type x86/x64:

All of the above appears to be correct but, all items with "[OperatingSystem] | WindowsVersion=XP_X64" in their .APM files are hidden. Only the "[OperatingSystem] | WindowsVersion=XP_X64,2K3_X64" .APM items are visible all of the time.
This is the case on both the VM and the real box.
On both boxes, updates KB2862152, IPsec; KB2868626, XML Digital Signatures; KB2875783, Kernel Memory; KB2876331, GDI; KB2933528, Password Security; KB3068404, VBScript, and all others with "[OperatingSystem] | WindowsVersion=XP_X64", are hidden when they should not be.
I can take any update with "[OperatingSystem] | WindowsVersion=XP_X64,2K3_X64" in its .APM file and hide it by removing the ",2K3_X64" portion of the text from the "WindowsVersion=" string.

All for now