ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE. Software > DcUpdater

DcUpdater reports incorrect version of installed app

(1/5) > >>


I have ScreenShotCaptor 3.03.01 installed (that's what its About box says) still DcUpdater reports I have 2.103.01 installed... and thus wants to upgrade.

What's up, doc?

It has to be getting the 2.103 from somewhere...

The file it uses is called "ScreenshotCaptor.dcupdate" in your screenshot captor program files directory.  See if you can find that file and open it in a text editor and see what it says.

The other thing you can do is in dcupdater, choose menu View -> Show Advanced Controls.  Then drag the bottom of the window up if it's all the way down, select Screenshot Captor in the main window, and see what it says for "DcUpdate File:"


The problem is that there was another file at:

C:\Users\sba\AppData\Local\VirtualStore\Program Files (x86)\ScreenshotCaptor\ScreenshotCaptor.dcupdate

that contained 2.103.01

This file was probably created by either:
- installing ScreenShotCaptor without using "run as administrator"
- running ScreenShotCaptor as a non-admin user just after installation

In either case, the file virtualization mechanism (introduced in Vista) has kicked in and redirected the attempt to write to C:\Program Files (x86)\ScreenshotCaptor (which a non-admin user is not allowed to do).

After I have deleted C:\Users\sba\AppData\Local\VirtualStore\Program Files (x86)\ScreenshotCaptor and relaunched ScreenShotCaptor, DcUpdater reports the correct version, BUT the file C:\Users\sba\AppData\Local\VirtualStore\Program Files (x86)\ScreenshotCaptor\ScreenshotCaptor.dcupdate has been recreated.

Unfortunately I fear that at the next update ScreenShotCaptor might update C:\Users\sba\AppData\Local\VirtualStore\Program Files (x86)\ScreenshotCaptor\ScreenshotCaptor.dcupdate, leaving C:\Program Files (x86)\ScreenshotCaptor\ScreenshotCaptor.dcupdate unchanged, causing another version discrepancy.

Another explanation would be that running ScreenShotCaptor as an admin user will populate C:\Program Files (x86)\ScreenshotCaptor\ScreenshotCaptor.dcupdate, whereas running an update check from within ScreenShotCaptor running as non-admin user will cause DcUpdater to look at C:\Users\sba\AppData\Local\VirtualStore\Program Files (x86)\ScreenshotCaptor\ScreenshotCaptor.dcupdate.

Get the picture?

IMVHO running an app should not populate a per-user file containing version information. Instead, the app's installer should populate a system-wide file containing version information. But I'm just wearing my software developer hat on here ;-)

P.S. Without Process Monitor I would not have been able to troubleshoot this.

Great detective work.

The part that confuses me is how that virtualstore copy of ScreenshotCaptor.dcupdate is being created in the first place..

That file should ALWAYS and ONLY be created during the installation process, which is always run as administrator (and thus has permission to write into the real Program Files (x86)\Screenshot Captor directory..  Running Screenshot Captor should not create this file in any scenario -- and I can't find any code where it does. 

Whether you run Screenshot Captor as admin or not should not result in the creation of a .dcupdate file.  Nothing should be able to create this file other than the installer.  Very odd.

The plot thickens.

Here's what I have just done (running as a non-admin user):

- shut down ScreenShotCaptor
- destroy both C:\Users\sba\AppData\Local\VirtualStore\Program Files (x86)\ScreenshotCaptor and
C:\Users\sba\AppData\Local\VirtualStore\Program Files (x86)\DcUpdater directories
- launch ScreenShotCaptor -- nothing happens in the virtualstore
- perform an update check using ScreenShotCaptor's context menu: this launches DcUpdater which recreates both directories with the following contents:

Installables        dcupdater.dcupdate

ClipboardHelpAndSpell.dcupdate  ProcessTamer.dcupdate
FindAndRunRobot.dcupdate        ScreenshotCaptor.dcupdate
FlipbookPrinter.dcupdate        TheFormLetterMachine.dcupdate
LaunchBarCommander.dcupdate     URLSnooper.dcupdate
PointMotivator.dcupdate         UnicodeImageMaker.dcupdate


Could be that DcUpdater attempts to update part of this in the non-virtualized directory (or just opens files in read-write mode even if it just wants to read?), this fails, causing the virtualization to do its magic?


[0] Message Index

[#] Next page

Go to full version