JDK-6786492 : 6u10 Uninstall fails to stop JQS, blocks installation of 6u14.
  • Type: Bug
  • Component: install
  • Sub-Component: install
  • Affected Version: 6u10p,6u11,6u29
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-12-17
  • Updated: 2011-11-08
  • Resolved: 2009-05-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u14 b07Fixed 7Fixed
Related Reports
Duplicate :  
JDK-6765283 - FilesInUse logic allows jqs.exe process running before install to cause Error 25099 during install
Relates :  
JDK-6831370 - JRE Installation Failed leves the files in a half way - Bad User experience.
Relates :  
JDK-7108484 - MSI installer failed to extract the binaries and installation would leave system JRE.
Description
We had uninstalled all versions of Java and even restarted. But, the
solution was that there was stil a "Java" folder in her "Program
Files" folder. Upon attempting to remove it, it reported it was in
use. So I called up the task manager and killed the jqs.exe file, and
then removed the "Java" folder successfully. Upon completing that
task, we were able to successfully install the update 11 without
issue. I hope this helps and please feel free to ask any questions."

We did this because we recieved error 25099 during trying to install 6u11.
Comments
EVALUATION We should continue to evaluate the above enhancements for 6u16's uninstall to more reliably stop the JQS. However, for 6u14 we need an extremely low-risk solution to help the majority of our users: those using Group Policy to deploy 6u14 over 6u10/6u11 uninstallations that FAILED to stop JQS. Those users are stuck without manual intervention...e.g., creating another policy that stops JQS, then running their 6u14 update policy, hacking together transforms that delete the JQS Service, etc. Therefore, the abstract is being updated to accurately depict what is needed for 6u14, especially given the fact that we cannot update the 6u10/6u11 uninstallers. Proposed fix for 6u14 is to stop the JQS service prior to installation. This can very easily be accomplished by adding 1 line to the ServiceControl table for the msi. By adding this line, the jqs service will be stopped, but not uninstalled...so that PIP will not be potentially broken. If the service does not exist, or is not running, MSI will skip the ServiceControl entry. Propose integrating this fix into b07.
07-05-2009
EVALUATION In addition to the above, there is another section of the code that is problematic, and is the cause of this particular case (via Raghu). When UninstallJRE() is called via the MSI during uninstall, we call FindJavaHome() to find the targetdir. The problem is all of the logic that performs uninstall functions (stopping services, deleted files/dirs, etc.) is wrapped inside a condition for FindJavaHome() returning TRUE. Thus, if FindJavaHome() fails, we fail to stop the JQS service. We don't need to find the Java home directory to stop the JQS service, so we should really be stopping the JQS service regardless of return code from FindJavaHome(). This would be enhancement #2 to our JQS shut-down logic. After the above shut-down enhancements are in place, we will need to add a custom action that is run BEFORE 6u14 is installed that leverages the new shut-down logic. This would address 6u13, 6u12, 6u11, and 6u10 users who have environments that would not otherwise allow 6u14+ revisions to be applied to the host because of core.zip failure. The implementation of the above is in progress.
30-04-2009
EVALUATION The previous evaluation is incomplete and not entirely accurate... Upon further investigation, there is a path to the function that shuts down jqs in BOTH the uninstall and patch-in-place installer logic: Uninstall -> regutils::UninstallJRE()->regutils::UninstallJQS()->regutils::StopJQSService() PIP-> regutils::UninstallJavaRegSet()->regutils::UninstallJQS()->regutils::StopJQSService() So the problem is not that the required functionality is not being called for PIP. The problem is that it takes some time for msvcr71.dll to free up from jqs.exe. This is demonstrated in the Uninstall logic: // RemoveInstalledFiles() must execute after JQS is stopped // but only during JRE uninstall, not patch-in-place, install, or JDK uninstall if (UninstallJRE_State == DURING_JRE_UNINSTALL) { int nsleep = 0; do { if (nsleep > 0) { WriteLogFile("-- Retrying RemoveInstalledFiles"); } if (RemoveInstalledFiles(lpszJavaHome) == ERROR_SUCCESS) { break; } // sleep 1 second. I've seen it take 3 seconds after UninstallJQS() // until msvcr71.dll can be deleted. ::Sleep(1000); nsleep += 1000; } while (nsleep < 6000); } This type of do-while attempt, be it based on an arbitrary time value that is qualitatively acceptable, or based on a factor of developer's machine benchmark, is problematic. Further, the above illustrates a hole for PIP...if the dll is being updated by PIP (doesn't need to be removed, but does need to be unloaded), the above logic isn't even executed, and there's no similar logic for non-uninstall scenarios. We really need to avoid this kind of workaround coding all-together. I propose the following fix: 1. Before StopJQSService(), enum all modules loaded by jqs.exe. 2. After StopJQSService(), wait for any loaded modules to be unloaded. I have implemented code in the FilesInUse class that does this, should not be difficult to leverage that code here...
27-04-2009
EVALUATION Looks like JQS is stopped via a custom action in the installer called in the InstallExecuteSequence. The chain goes something like this: InstallExecuteSequence -> UninstallJQS (customaction) -> MSIUninstallJQS (regutils.dll) -> UninstallJQS (regutils.msi) -> StopJQSService (regutils.msi) In the log file the UninstallJQS customaction is skipped. A look at the condition set in the InstallExecuteSequence reveals why it was skipped: Mode = "U" Looks like this CA should be called for uninstalls in addition to upgrades.
18-12-2008