Hey Greg I am getting pretty swamped right now. Can you please take a look at this issue or reassign to someone else?

Could you attach the exact file that exhibits the problem? Thanks.

Greg, I created this condensed version according to the user instructions. The characters around the error location match his description. I am not sure the original reported did follow this bug after I created it from his chromium-discuss post.

I won't see this is very urgent but it is worth checking if there is an issue with our code there.

Deleted: master_preferences 1.0 KB

master_preferences 1.0 KB View Download

There doesn't appear to be anything wrong with the master_preferences file provided as-is. My suspicion is that the command line with the encoded master_preferences file is too long, so the file is truncated. This can be confirmed by capturing the file written by Google Update and passed to Chrome's installer via the /installerdata="C:\Windows\TEMP\gui+++.tmp" command line option. If you're lucky, Chrome's installer copies this into C:\Program Files (x86)\Google\Chrome\Application\master_preferences, so it may suffice to inspect that file. If you're not lucky, it deletes the file without copying it because it can't be read, but I don't think that's the case.

Can please try to verify your hypothesis?

While I haven't tried mutating an .MSI, passing the attached prefs file to Chrome's installer via --installerdata works like a charm. I'm pretty sure the problem is that the data is just too big for the command line. A procmon trace will probably confirm this -- look for the "Process Create" event that contains the installerdata string.

There's a lot of fat that can be trimmed from this master_preferences file. I believe that the following will result in the same behavior:

{
  "bookmark_bar":{
    "show_on_all_tabs":true
  },
  "browser":{
    "check_default_browser":false,
    "show_home_button":true
  },
  "distribution":{
    "allow_downgrade":true,
    "do_not_create_any_shortcuts":true,
    "do_not_register_for_update_launch":true,
    "msi":true,
    "suppress_first_run_bubble":true,
    "suppress_first_run_default_browser_prompt":true,
    "system_level":true,
    "verbose_logging":true,
    "welcome_page_on_os_upgrade_enabled":false,
    "show_welcome_page":false,
    "skip_first_run_ui":true
  },
  "homepage":"http://my.custom.page.org/",
  "homepage_is_newtabpage":false,
  "session":{
    "restore_on_startup":4,
    "startup_urls":[
        "http://my.custom.page.org/"
    ]
  },
  "sync_promo":{
    "show_on_first_run_allowed":false,
    "startup_count":10,
  }
}

Maybe this one is small enough to fit within the space provided?

I'll describe what I've changed here:

This pref:
    "do_not_create_any_shortcuts":true,
makes all of the following pointless:
    "do_not_create_desktop_shortcut":true,
    "do_not_create_quick_launch_shortcut":true,
    "create_all_shortcuts":false,
    "do_not_create_taskbar_shortcut":false,
Note in particular that setting do_not_create_taskbar_shortcut to false in an attempt to create the taskbar shortcut doesn't work -- the suppression overrides the desire for creation. That said, the taskbar shortcut cannot be created under any circumstances on Win10+.

This pref:
    "system_level":true,
makes this one a noop:
    "do_not_launch_chrome":true,
so the latter can be removed.

These all set their respective prefs to their default values, so they can all be removed:
    "disable_logging":false,
    "make_chrome_default":false,
    "make_chrome_default_for_user":false,
    "require_eula":false,

This one is being used wrong, so it can be removed:
    "suppress_default_browser_prompt_for_version":true,

This one shouldn't be needed:
    "user_skipped":true,

And this one doesn't seem to exist:
    "view_count":1

I also suggest setting this to 10 for maximum effect:
    "startup_count":10,

I've verified that this prefs data with the two modifications below works in the sense that it is not being truncated by any MSI machinery or command line parsing:

- Remove the trailing comma on the "startup_count" pref (this trips me up every time).
- Add the distribution.msi_product_id pref. The value of this preference changes with each build, so you must find the value in the msi you're modifying and be absolutely certain to propagate it to your new prefs data.

{
  "bookmark_bar": {
    "show_on_all_tabs": true
  },
  "browser": {
    "check_default_browser": false,
    "show_home_button": true
  },
  "distribution": {
    "allow_downgrade": true,
    "do_not_create_any_shortcuts": true,
    "do_not_register_for_update_launch": true,
    "msi": true,
    "msi_product_id": "INSERT PRODUCT ID GUID HERE",
    "show_welcome_page": false,
    "skip_first_run_ui": true,
    "suppress_first_run_bubble": true,
    "suppress_first_run_default_browser_prompt": true,
    "system_level": true,
    "verbose_logging": true,
    "welcome_page_on_os_upgrade_enabled": false
  },
  "homepage": "http://my.custom.page.org/",
  "homepage_is_newtabpage": false,
  "session": {
    "restore_on_startup": 4,
    "startup_urls": ["http://my.custom.page.org/"]
  },
  "sync_promo": {
    "show_on_first_run_allowed": false,
    "startup_count": 10
  }
}

For today's x64 stable MSI, the product ID pref is:
    "msi_product_id": "BE40B3E0-129E-313C-B663-94C192C5143F",
Do not simply copy this value in to a prefs file that you use for anything other than today's 56.0.2924.87 x64 MSI.

I'm closing this out as WontFix. To be honest, I don't know what the problem was. I'm able to run an MSI with the original prefs data without issue. To diagnose further I'll need to see either a verbose omaha log or a procmon log so I can see the exact command lines being passed from process to process. That said, please try the simpler data from this message to see if it works for you.

Thanks Greg! 

I think you have done enough documenting this issue and its investigation so that it will be useful for anyone looking about similar issues and in general about how to set master prefs correctly.