Thanks Sorin.
I had checked the code paths that could produce this
error. However, it was still unclear as to which path is producing it.
Unfortunately, the built version I’m working with isn’t generating all the log
message and those that would tell me the actual
reason isn’t making it to the log.
My first thought was one of the required parameters was
missing but they seem to be in the response.
I then checked that I was getting the same hash and file size as what was
generated when the updater/installer was uploaded to the server as
new version. They were the same as stored in the version page for this installer.
I am attempting to build the fork I have but I haven’t been
able to find the ATL Server headers needed for the build.
The fork is based on Omaha version 3 (not sure the minor version, if any).
Any idea why some CORE_LOG messages of the same level (L3) aren’t being emitted while others are? The bold line would tell me all I need but isn’t logged.
HRESULT PackageCache::Put(const Key& key,
const CString& source_file,
const FileHash& hash) {
++metric_worker_package_cache_put_total;
CORE_LOG(L3, (_T("[PackageCache::Put][key '%s'][source_file '%s'][hash %s]"),
key.ToString(), source_file, internal::GetHashString(hash)));
__mutexScope(cache_lock_);
if (key.app_id().IsEmpty() || key.version().IsEmpty() ||
key.package_name().IsEmpty() ) {
return E_INVALIDARG;
}
Based on the XML received and a log message, I’m pretty sure we have an app id, version, and package_name.
Here is a log snippet
:goopdate][23564:20680][DownloadManager::DoDownloadPackage][appid={CAC2F6B2-855A-4FB3-90DE-4C1E43F2E711}; version=5.0.0.1; package_name=Install-XXXXXXXXXX-5.0.0.1.exe]
It could also be this call returning the E_INVALIDARG, but I
doubt it.
HRESULT hr =
BuildCacheFileNameForKey(key, &destination_file);
Or these from PackageCache::Put:
hr =
CreateDir(GetDirectoryFromPath(destination_file), NULL);
if (FAILED(hr)) {
CORE_LOG(LE, (_T("[failed to create cache directory][0x%08x][%s]"),
hr, destination_file));
return hr;
}
// TODO(omaha): consider not overwriting the file if the file is
// in the cache and it is valid.
// When not impersonated, File::Copy resets the ownership of the destination
// file and it inherits ACEs from the new parent directory.
hr = File::Copy(source_file, destination_file, true);
if (FAILED(hr)) {
CORE_LOG(LE, (_T("[failed to copy file to cache][0x%08x][%s]"),
hr, destination_file));
return hr;
}
hr = VerifyHash(destination_file, hash);
if (FAILED(hr)) {
CORE_LOG(LE,
(_T("[failed to verify hash for file '%s'][expected hash %s]"),
destination_file, internal::GetHashString(hash)));
VERIFY1(::DeleteFile(destination_file));
return hr;
}
If the hash and file length is the same as what is provided in the XML response, would there be a failure with VerifyHash?
I’m not sure why the CORE_LOG(LE messages aren’t making it to the log file. They would be very helpful. Especially
since they are error messages, and I would have expected those to always be included in the log.
This only happens with the newly created version install I uploaded to the Omaha server. Previous versions work fine.
Thanks again,
Thom Bentley
Thanks Sorin.
I had checked the code paths that could produce this error.
However, it was still unclear as to which path is producing it.
Unfortunately, the built version I’m working with isn’t generating all the log message and those that would tell me the actual
reason isn’t making it to the log.
My first thought was one of the required parameters was missing but they seem to be in the response.
I then checked that I was getting the same hash and file size as what was generated when the updater/installer was uploaded to the server asnew version. They were the same as stored in the version page for this installer.
I am attempting to build the fork I have but I haven’t been able to find the ATL Server headers needed for the build.
The fork is based on Omaha version 3 (not sure the minor version, if any).
Any idea why some CORE_LOG messages of the same level (L3) aren’t being emitted while others are? The bold line would tell me all I need but isn’t logged.
I’m not sure why the CORE_LOG(LE messages aren’t making it to the log file. They would be very helpful. Especially
since they are error messages, and I would have expected those to always be included in the log.
This only happens with the newly created version install I uploaded to the Omaha server. Previous versions work fine.
--
You received this message because you are subscribed to the Google Groups "Omaha Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omaha-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/2fbded61-9454-40fd-9233-f4abfcf24e6bn%40googlegroups.com.
However, it was still unclear as to which path is producing it.
This only happens with the newly created version install I uploaded to the Omaha server. Previous versions work fine.
To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/fef8bcce-990e-44dc-bfbb-c751ebf2bdban%40googlegroups.com.
However, it was still unclear as to which path is producing it.
>> I agree although `0xa043050d` is only generated at a specific call site.GOOPDATEDOWNLOAD_E_CACHING_FAILED is returned from DownloadManager::CachePackage in one place, but there are several places in push that can cause an error that wouldresult in a GOOPDATEDOWNLOAD_E_CACHING_FAILED when handled by DownloadManager::CachePackage.Some of the calls that Put makes can return an E_INVALIDARG error and it's not clear which one is causing the actual failure.
I'm working on building the code that is having the issue, but running into many issues with the build and setup for the build.
To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/6a71d185-807d-4998-98c9-093cc885a950n%40googlegroups.com.
Hi Sorin,
Thanks again.
Are you saying the log message confirms that there is a problem with the hash verification?
If so, that's confusing because previously created versions on the update server can be downloaded and installed without any errors.
I would expect the same to be true of a new version added to the same server since the server being used did the hash for the older installs.
I'm even using the same setup.exe (our ProductSetup.exe renamed to setup.exe)
If the server is creating a SHA1 hash and the client is expecting a SHA256, then I'm at a loss for why.
To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/c24bc593-3a54-4789-ba09-610b8674c2d1n%40googlegroups.com.
Hi Sorin,
I don't know how the fork was created and why a trunk was used. The fork was created by Omaha Consulting and modified so it could be our product's installer/updater in the Fall of 2019 or so.
All this happened well before I got involved.
I'll reach out on LinkedIn since I don't have your email.
To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/827cd5d0-a2c4-4694-960d-33ba0d1e8654n%40googlegroups.com.
Hi Sorin,
I got a little further on Friday after realizing that all of VC++ components hadn't been installed even when it seemed I had selected the right options initially. However, scons doesn't seem to find it/
> hammer.bat
scons: warning: No installed VCs
File "C:\swtoolkit\trunk\site_scons\site_init.py", line 426, in SiteInitMain
scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly
File "C:\swtoolkit\trunk\site_scons\site_init.py", line 426, in SiteInitMain
scons: Reading SConscript files ...
scons: warning: No installed VCs
File "C:\swtoolkit\trunk\site_scons\site_tools\target_platform_windows.py", line 283, in generate
scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly
File "C:\swtoolkit\trunk\site_scons\site_tools\target_platform_windows.py", line 283, in generate
Warning: Unable to load win32file module; using copy instead of hard linking for env.Install(). Is pywin32 present?
Using precompiled headers.
Building versions: 1.3.99.0
To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/9f943190-05bf-4eed-b868-db635fd6ad70n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/c87387cd-20af-4c7a-a1c8-78879712c7bdn%40googlegroups.com.
Thanks
After I made sure I was using the right SDK by setting it with: "%ProgramFiles(x86)%\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 10.0.10586.0, it cleared the compiler errors.
That got the right include directory and the right headers to avoid the BOOLEAN/bool issue.
You were right about the warning about no compiler being found. Glad it worked without it finding the value in the registry. Why isn't it finding the right info in the registry? Code too old?
To view this discussion on the web visit https://groups.google.com/d/msgid/omaha-discuss/f8aea81d-664a-421f-a799-0effaac2b064n%40googlegroups.com.