Video Screencast Help

Add-ins cause error 1606 on Word 2010 launch

Created: 16 Dec 2013 • Updated: 19 Dec 2013 | 22 comments
This issue has been solved. See solution.

Hi, I wonder if anyone can shed some light on this?

I have Office 2010 captured on Win XP sp1 and running on Win 7 sp1.

If I add an application which includes an office addin as a seperate layer, I get this error when launching Word 2010:

Error 1606. Could not access network location

[:B_]APPDATA:USER_TEMPLATE[_E_]\Microsoft\MSDN\8.0.

The beginning of the variable does not look correct to me.  I guessed it should be [_B_] , but I may be wrong on this.

If the variable is wrong, that would explain why the path couldn't be accessed. I have been unable to find any reference to [:B_] in the registry or by a file search.

 Other than this one issue, the layer works fine.

[UPDATE] Using the same layers in Win XP, the problem does not occur.  I'm hoping I can find a way to avoid a re-capture in Win7.

 

Error1606.JPG

Operating Systems:

Comments 22 CommentsJump to latest comment

Gopinath Muniyandi's picture

Hi Lee,

This looks like a package issue; check this MS article:

http://support.microsoft.com/kb/886549

Please create a support ticket if you still need help.

Regards,

Gopinath M

ksreek's picture

While it is certainly safe to consider this as a packaging issue, the variable path is still wrong !! .You are correct the Begin & End tag has to be in the format [_B_] & [_E_] respectively which is why it fails to resolve that path.

We use to see this error message in the past and might related to our Variablization issues we have fixed  (Environmental variables being rendered incorrectly). We are curious to know what version of SWV was used for capture as well as rendering the package at the endpoint ?. We have variablization issues fixed in our SWV 7.5 release and a couple of them in SWV 6.1 SP8.

Alternatively try replacing the [:B_]APPDATA:USER_TEMPLATE[_E_] references with your actual profile path using the layer editor and then try launching Word. We are interested to know how it turns out when you capture this package in Win 7 as you have no issues accessing the same package in Winxp !!

Cheers !

 

LeeMitchell's picture

Thanks for your responses.

I'm using SWV 6.1 SP8 on both the Win Xp capture VM and the Win 7 endpoint.

I'll try using the layer editor first and I'll let you know how I get on.

Cheers

delvalled's picture

Lee,

We have an issue matching these symptoms that is marked as resolved in our 7.5 release. Note the syntax of the SWV variable:

[:B_]APPDATA:USER_TEMPLATE[_E_] 

This is incorrect; instead it should read:

[_B_]APPDATA:USER_TEMPLATE[_E_]

Your MSI file is probably just fine.

From the notes I have, this problem is happening because msiexec.exe is running as Administrator and reads a registry value that has a user variablized path. Since there isn't a profile that has a USER_TEMPLATE defined, it fails and returns the variablized data. The app doesn't know what to do with it and fails. We corrected this behavior by changing how we acquire the SID from the impersonated thread instead of from Process Id.

Please upgrade to the latest version and try to reproduce the problem again. Also, if you can provide very specific steps to reproduce the error, I can validate the same in my environment.

-Danny

LeeMitchell's picture

I was ununable to find any references to [:B_]APPDATA:USER_TEMPLATE[_E_] using layer editor, or by unzipping the .xpf and viewing each of the .xml files. 

The MSI that is called when Word is launched with add-ins produces a log that captures the error.  Here is some of the output:

%USER%\[_B_]TEMP[_E_]\MSI92a1e.log

Error 1606. Could not access network location [:B_]APPDATA:USER_TEMPLATE[_E_]\Microsoft\MSDN\8.0.

Property(S): DR_57480.3643236F_FC70_11D3_A536_0090278A1BB8 = C:\Users\Admin.TEST\AppData\Roaming\Microsoft\MSDN\

Property(S): DR_57481.3643236F_FC70_11D3_A536_0090278A1BB8 = [:B_]APPDATA:USER_TEMPLATE[_E_]\Microsoft\MSDN\8.0

The msi property "DR_57481.3643236F_FC70_11D3_A536_0090278A1BB8" exists in C:\Windows\Installer\1cd367.msi

As you can see, the parent directory resolves the variable correctly.  The user shell folders keys in the package and on the base all appear to be correct.  I have even tried editing the C:\Windows\Installer\1cd367.msi using Orca to see if the rogue SWV variable, or a corrupt entry was present in the directory or properties table, but it all looked to be correct.

If I can work out how the SWV variable is picked up by the MSI, I'll be a happy chap!

 

EdT's picture

It would be useful to see the entire log of which the previous posting shows a very small part. My suspicion is that the MSI Server process (shown by the (S) after Property) is not able to correctly resolve user specific data, possibly due to a flawed custom action in the MSI, and is also guilty of the substitution of [_B_] by [:B_] - ie it's parsing the SWV variable as a path text string but lacks the necessary access to correctly resolve it.

Also - an obvious question: does the actual path exist in the user profile?  If it does not, then you are also going to get problems.  Finally, with some addins, there may be a requirement to set the add-in as trusted. This involves setting a registry key in the user profile if I recall correctly. 

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

LeeMitchell's picture

The path exists within the RO layer USER_TEMPLATE\[APPDATA]\Microsoft\MSDN\8.0

After capture the path did not contain any files, and none were leaked to the base.  I have tried adding a text file to the path so it was not empty, but this made no fifference.

I'll check out whether the addins trusted.  It may be worth knowing that the addins are included with an app in a layer seperate to my Office 2010 layer.  If the other app layer containing the addins is disabled, Word starts ok. (The path didn't exist in the other app layer, tried adding it with layer editor in case it made a difference, which it didn't)

Here is the entire log contents as requested:  Thanks for looking

Attached MSI92a1e.LOG to reduce the post size.

AttachmentSize
MSI92a1e.LOG_.txt 153 KB
EdT's picture

The line in the log which has:

Property(S): DR_57481.3643236F_FC70_11D3_A536_0090278A1BB8 = [:B_]APPDATA:USER_TEMPLATE[_E_]\Microsoft\MSDN\8.0

appears to be caused by a problem that the MSI has had in resolving the property value at runtime, yet the issue is not apparent in the similar property:

Property(S): DR_57480.3643236F_FC70_11D3_A536_0090278A1BB8 = C:\Users\Admin.TEST\AppData\Roaming\Microsoft\MSDN\

This you have already mentioned, but where you stated:

The msi property "DR_57481.3643236F_FC70_11D3_A536_0090278A1BB8" exists in C:\Windows\Installer\1cd367.msi

-can you specify what value this property is set to ?

-can you confirm whether the MSI 1cd367.msi is located in the base at c:\windows\installer, or is located in the layer at c:\windows\installer, or both?  If both, are the two files identical?

Does the property DR_57480.3643236F_FC70_11D3_A536_0090278A1BB8 also exist in this MSI?  If so, what value is it set to ?

Are you able to attach the MSI file 1cd367.msi ?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

EdT's picture

One further thought - the first time that you start Word with an add-in installed, presumably the running of the MSI makes some system changes which are not repeated on subsequent startups. A better fix might be to capture these changes with Office installed in the base and build them into your add-in layer so that the MSI never needs to run.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

LeeMitchell's picture

Really appreciate you helping me with this one. Thanks.

- I'm afraid I got my words mixed up when I mentioned the msi property. The entry is in the directory table of the msi, not the property table.  The details, if still needed, are:

Directory  Directory Parent  DefaultDir
DR_57480.3643236F_FC70_11D3_A536_0090278A1BB8 AppData_Microsoft.3643236F_FC70_11D3_A536_0090278A1BB8 MSDN|MSDN:MSDN|MSDN
DR_57481.3643236F_FC70_11D3_A536_0090278A1BB8 DR_57480.3643236F_FC70_11D3_A536_0090278A1BB8 8.0|8.0:8.0|8.0

1cd367.msi is located within the layer at C:\Windows\Installer

I've attached the msi.

Thanks again

 

AttachmentSize
1cd367.zip 9.38 MB
LeeMitchell's picture

That's a good idea. While office was installed on the base before the app capture, I know it wasn't launched during the capture of the app. 

I'll give that a go now.

 

ksreek's picture

Snippet : "The MSI that is called when Word is launched with add-ins produces a log that captures the error.  Here is some of the output:

%USER%\[_B_]TEMP[_E_]\MSI92a1e.log

Error 1606. Could not access network location [:B_]APPDATA:USER_TEMPLATE[_E_]\Microsoft\MSDN\8.0.

Property(S): DR_57480.3643236F_FC70_11D3_A536_0090278A1BB8 = C:\Users\Admin.TEST\AppData\Roaming\Microsoft\MSDN\

Property(S): DR_57481.3643236F_FC70_11D3_A536_0090278A1BB8 = [:B_]APPDATA:USER_TEMPLATE[_E_]\Microsoft\MSDN\8.0"

Office usually takes full advantage of the self-repairing features offered by the Windows Installer. So, if a critical resource is missing, such as a file or registry key required to start an Office program, the Windows Installer detects this and attempts to repair. Windows installer records all resources within a component.Typically a file is chosen as the keypath, but it could also be a registry value as well.The keypath represents two things:

1.) The path to a specific component

2.) When an application requests a path to a component, the Windows Installer returns the path to the keypath resource verifying whether the component is properly installed. If the keypath resource is missing, the Windows Installer treats the whole component as broken.

What I wonder is that, if SWV agent's vaiablization causes this impression to Windows Installer causing to trigger this whole sequence (due to the bad path [:B]) ??  In any case testing the SAME layer in a client machine with SWV 7.5 installed might help to isolate SWV out.

I know this fact is a high level postulation of the MSI stuff but this is what i can think as of now based on the witnesses involving SWV.

EdT's picture

One further addition to kskreek's posting is that any requirements to repair an MSI based application at startup (or any other time for that matter) are logged to the application event log, and list the component GUID{s} of any components with a missing key path.  So it may be worth having a look in the app event log and check whether there are any related entries.

There is some overlap between "directory" entries and "properties"  According to the directory table, the entry starting DR_57481 is a subdirectory of the directory table entry starting DR_57480 and therefore it would seem that if 57480 is correct, then 57481 should be correct also, but that is not the case based on the log entry.

The log itself is not a verbose log, and hence there would appear to be some other processes affecting the outcome. I refer to enabling verbose logging later in this post.

The Directory Parent entry for 57480 is:

AppData_Microsoft.3643236F_FC70_11D3_A536_0090278A1BB8

but it does not appear anywhere in the log, and I suspect the resolution of this path is crucial to the problem. This path is actually derived via the custom action table where the entry concerned looks like this (Four columns which appear wrapped below):

AppDataFolder.3643236F_FC70_11D3_A536_0090278A1BB8   51 AppDataFolder.3643236F_FC70_11D3_A536_0090278A1BB8   [AppDataFolder]
 
(If you look further up the sorted DIRECTORY column, you will see that the AppData_Microsoft.3643236F_FC70_11D3_A536_0090278A1BB8 value is the parent folder for the AppDataFolder.3643236F_FC70_11D3_A536_0090278A1BB8 value.
 
What this entry means is that the value of the above directory properties ultimately resolves back to AppData, which I suspect may well be read from the registry.  You will note that the very first line of the log shows the basic error:
 Error 1606. Could not access network location [:B_]APPDATA:USER_TEMPLATE[_E_]\Microsoft\MSDN\8.0.
 
This happens because the windows installer process checks for the availability of ALL the directory table entries before installation commences and for some reason the appdata value is not coming back correctly. This MAY indicate a flaw in the SWV code.  The place in the registry where USER pointers to shell folder are stored is here:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
 
There is also a secondary list at:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders but this uses parameter substitution and I personally prefer to reference the first key.
 
It might be interesting to check what entries are actually present in the live user key - but you would need to load REGEDIT into the layer to be absolutely sure of what is going on in the virtual HKCU hive.
 
 
 
To enable verbose logging for when things go wrong you can either set this via group policy or via a registry hack:
 
To enable Windows Installer logging
To enable Windows Installer logging yourself, open the registry with Regedit.exe and create the following path and keys:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

Reg_SZ: Logging
Value: voicewarmupx

The letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter's actual function is as follows for MSI version 1.1:

v - Verbose output
o - Out-of-disk-space messages
i - Status messages
c - Initial UI parameters
e - All error messages
w - Non-fatal warnings
a - Start up of actions
r - Action-specific records
m - Out-of-memory or fatal exit information
u - User requests
p - Terminal properties
+ - Append to existing file
! - Flush each line to the log
x - Extra debugging information. The "x" flag is available only on Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.
Remember to delete this key after testing otherwise a verbose log will be generated in the temp folder for every MSI install thereafter, and these verbose logs can run to many Mb and eat up disk space.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

SOLUTION
ksreek's picture

Incredible additional notes @ EdT .. Impressed on your knowledge about the MSI workflow !!!

"" You will note that the very first line of the log shows the basic error:
 Error 1606. Could not access network location [:B_]APPDATA:USER_TEMPLATE[_E_]\Microsoft\MSDN\8.0.
 
This happens because the windows installer process checks for the availability of ALL the directory table entries before installation commences and for some reason the appdata value is not coming back correctly. This MAY indicate a flaw in the SWV code.  The place in the registry where USER pointers to shell folder are stored is here:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders ""

This is the flaw we are referring that we believe we may have fixed in SWV 7.5 already.

 So yes, the path resolution to that directory is crucial. So we wanted to eliminate SWV out of the picture i.e (If SWV 7.5 is still unable to resolve the path inspite of the variablization fixes included) then we are good. If not we must be relying the verbose logging to analyze the situation more closely on what we are missing.

LeeMitchell's picture

Some great points there.

The fact that a self repair is initiated is one problem, and that it cannot complete due to the invalid path is a second issue.

It's getting late in the UK, so I'll work through your recommendations and post an update tomorrow.

Thanks again

 

 

LeeMitchell's picture

Ok, I've got so hung up looking for the invalid variable, I never thought to do the MSI basics.

Edt, you were quite right, an event was created by the self repair, and it was pretty self explanatory:

Detection of product '{90140000-0011-0000-0000-0000000FF1CE}', feature 'ProductNonBootFiles', component '{EE6C0B94-C3A4-11D3-91C4-00600893B51B}' failed.  The resource 'C:\Program Files\Common Files\ODBC\Data Sources\' does not exist.

By simply adding the path to the RO layer of office, my problem has been fixed.

As the feature is no longer broken, the invalid path in the table appears not to be referred to.

As this was the only problem found after weeks of UAT, I'm happy to go with this for the time being.

I'll be performing another capture of office in the next few months when I enable Outlook and Sharepoint, so I now have a better idea of what to look for. 

At this point in time, there's no plan to upgrade our clients to SWV 7.5, though I'll bear your comments in mind ksreek.

I'm aware that the invalid path still exists, so I'll recreate the issue to prompt the self repair again, and enable verbose logging in an effort to identify.  It might take a few days to get around to this.  I'll post my reults when I have them.

Thanks again Edt and skreek for all your help.

EdT's picture

@kskreek

Could you review these two threads as they appear similar and both involve 7.5

It may not be a 7.5 issue at all, but a change in behaviour from an earlier version may well require users to give more thought to some aspects of packaging Office.

https://www-secure.symantec.com/connect/forums/symantec-virtualization-office2007-and-office2010-infopath-extension-issue

https://www-secure.symantec.com/connect/forums/issues-while-virtualising-office-2010-swv-75

 

Does the capture process in 7.5 include capturing empty folders created by an install ?  Failure to do this would account directly for the issue that this thread was all about.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

ksreek's picture

Am confident we don't ignore 'empty folder' creation triggered by install which is under capture (I just tested it). I am doing a couple of sanity tests internally with respect to those two threads and i wish to come back soon once i have completed analyzing the situation more closely. Thanks

LeeMitchell's picture

If it helps, the directory 'C:\Program Files\Common Files\ODBC\Data Sources\' already existed on the base of my Xp packaging VM when I tested the Office layer, which I thought explained why I didn't see the problem when used with XP.

Strangely, I thought this directory would be present on my Win7 VM when office was installed to the base, but it wasn't.  I then made my app layer with the word addin active and launched word.  The addin worked as expected yet the directory still wasn't present.

 

 

EdT's picture

There are some folder differences between XP and Win 7 which can cause issues like this. Win 7 does "fake" the XP folder structure to some extent, but by capturing on XP, any registry pointers to folder locations that are specific to XP will not change in your layers when you run on Win 7. It may well be that the equivalent ODBC folder on Win 7 is somewhere else, like under ProgramData, and a capture on Win 7 would cause the equivalent registry settings to be configured appropriately for the Win 7 folder structure.

It may be interesting to search your RO layer's registry for any pointers to the missing folder C:\Program Files\Common Files\ODBC\Data Sources, then check the same registry key on a native Win 7 installation of office.

When you come to package for 64 bit, be aware that many of the Adobe CS6 products have separate installers for 32 bit and 64 bit, and my experience is that the 32 bit versions will not run on 64 bit.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

EdT's picture

One further thing occurs to me. The event log entry you reported:

Detection of product '{90140000-0011-0000-0000-0000000FF1CE}', feature 'ProductNonBootFiles', component '{EE6C0B94-C3A4-11D3-91C4-00600893B51B}' failed.  The resource 'C:\Program Files\Common Files\ODBC\Data Sources\' does not exist.

-if you are getting this on 64 bit Win 7 (you don't appear to have been specific on whether your Win 7 test machine is 32 bit or 64 bit) then the error refers to a 64 bit path, which of course does not exist in a 32 bit layer. This also comes back to ksreek's note that creating packages on XP for XP machines and on Win 7 for Win 7 machines avoids some of the 32/64 bit issues if you are running 64 bit versions of Win 7, which tends to be the norm these days.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

LeeMitchell's picture

Both were 32 bit machines. Sorry I forgot to mention that.

Packaging for Win7 64 bit is something I've got to look forward to in the new year.