{GOOGLECHROME} Placeholder Fails

  • Stephen Brinich

    Stephen Brinich - 2013-02-23

    When I try to use one of my URL entries with a pointer to Google Chrome, I now get an error message:


    Access is denied

    Apparently the {GOOGLECHROME} placeholder now points at the admin account. The only relevant change I can think of is the latest Google Chrome update. Other placeholders such as {FIREFOX} appear to work correctly (though for some reason it opens two windows).

  • Paul

    Paul - 2013-02-24

    The Chrome place holder detection method was updated in KeePass V 2.20.1. Have you tried an earlier/later version?

    cheers, Paul

  • Stephen Brinich

    Stephen Brinich - 2013-02-24

    I've been using the latest version (2.21) -- it worked fine before now (the only relevant event I know of was the latest Chrome update).

  • wellread1

    wellread1 - 2013-02-24

    {GOOGLECHROME} seems to work fine for me with Chrome 25.0.1364.97 m, KeePass 2.21, Win 7 Home edition x64. Is KeePass "Run as Administrator" by any chance?

    When I try to use one of my URL entries with a pointer to Google Chrome, I now get an error message:

    Is the problem only with one entry or all entries that use the {GOOGLECHROME} placeholder?
    Can you provide the specific URL string that is failing?

    • Stephen Brinich

      Stephen Brinich - 2013-02-28

      For example, I get the error message when using the URL string:

      cmd://{GOOGLECHROME} https://login.yahoo.com/

  • Stephen Brinich

    Stephen Brinich - 2013-02-28

    I managed to fix the problem by:

    1. Running Chrome from the Windows command line (type "chrome-RETURN" in the Start menu text box) in my user account. This resulted in a popup saying that Chrome was installed by an administrator (as usual, I ran the software install from the admin account) for all users, and Windows would replace the admin-install settings with local-user settings.

    2. Exiting and re-starting KeePass (trying the URL again before doing this got the same old error; afterwards, the URL worked as expected).

    The origin of the oddity may be that I installed the latest Chrome update via Ninite rather than directly; the Ninite installer may have chosen a bad option as part of its "block tag-along-ware without user intervention" processing.

    Last edit: Stephen Brinich 2013-02-28
  • wellread1

    wellread1 - 2013-02-28

    Thanks for posting the solution.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks