Hello, I have some computers were WebUpdate can't update the application. I have compiled webupdate with UAC, but in the end of the process the files can't be updated.
This is the log, but I see no errors in it.
<!--if gte mso 9>
<o:OfficeSettings>
<o:AllowPNG/>
</o:OfficeSettings>
I see that in the last stage, where a spawned updater app should replace the EXE there must be an issue.Two reasons I can see: 1) the spawned updater has no permissions (UAC did not raise succesfully to admin level) to replace the EXE in c:\program files or 2) the EXE is still kept in memory (multiple running instances? closing blocked?) and can't be replaced.
Can you check these 2 possible causes?
Thank you for the quick response, I think is the first one. Why UAC can not raise sucessfully to admin level?
I assume you get the UAC prompt and do you accept it to elevate to admin level (to have permission to update the EXE under \Program Files?
No, I don't get the UAC prompt in the machines I have the problem.
Are you 100% sure you compile WebUpdate with UAC enabled (default)?
Yes, I also have added a progress message that shows if the property UAC Enabled is true or false.
I store the log in Program Files\App\log\wupdate, then the user can write to Program Files folder.
To begin with, did you try the basic sample application that is included and can you verify you see the UAC prompt there at the moment the spawned updater app launches?
We are working with webupdate for years without problem. We have this problem with one customer, and in some computer UAC prompt is raised and not in others.
Did they disable things in these specific machines?
Things like?
I don't know, all i can do is pure guesswork if you do not provide any details on what happened with these machines.
Things like:
and perhaps others? Or 3rd party software that got installed?
Is there any option to get a log when spawn is executed and can't do work?
Can you check if there was a log created for the spawned updater app under \My Documents in WUPDATE.LOG?
This is the content of wupdate file
<!--if gte mso 9>
<w:Word>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:Trackatting/>
<w:HyphenationZone>21</w:HyphenationZone>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfInvalid>false</w:SaveIfInvalid>
<w:IgnoreMixed>false</w:IgnoreMixed>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DonotPromoteQF/>
<w:LidThemeOther>ES</w:LidThemeOther>
<w:LidThemeAsian>X-NONE</w:LidThemeAsian>
<w:LidThemeComplex>X-NONE</w:LidThemeComplex>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndark/>
<w:EnableKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
</w:Compatibility>
<w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:Word>
This indicates there was a failure to overwrite the existing EXE
2 most common reasons:
1) UAC didn't raise to admin permissions so \Program Files folder remains write protected
2) The running EXE (gestlab.exe) could not be closed or there are multiple instances running and as long as it is kept in memory, Windows prevents replacing it.
I think is number one, and then the log can't show the cause that makes UAC not raise.
Do the users get the UAC prompt?
If not, clearly, they have tampered with their Windows setup.
Hello Bruno, It seems that the problem is solved executing the application with Windows XP service pack 3 mode compatible.
Where can be the source of the issue?