I've started building Linux installers on the 64 bit windows version of Install4j recently and am getting the error below when it the generated installers start to do their extraction.
Is this something I'm doing wrong or is unsupported? Or a bug in 5.1 of install4j. I've recently upgraded to it as well.
Extracting files ...
yxN
An error occurred:
java.lang.IllegalArgumentException: Negative time
Error log: /tmp/install4jError8217531393990762392.log
java.lang.IllegalArgumentException: Negative time
at java.io.File.setLastModified(Unknown Source)
at com.install4j.runtime.installer.helper.fileinst.FileInstaller.install(Unknown Source)
This turned out to simply be a corrupted custom JRE being included in the installer.
Had the same issue. Due to an independent reason one of the files contained in the source directory had a file date in the year 1961.
Since most calenders starts at 198ß a check of that results in a negative timestamp.
After setting a current date the build process worked fine.
So it was not denepending on any version of jdk and had nothing to do with any broken jre installations or something like that.
Hint: In the windows exploerer no file date was shown. This might be helpful for anyone having a similar source file since you won't notice a wrong date as long you don't see it.
Search for file with dates before 1980 or use a commander should help you to find that ones.
Related
Been using this Eclipse workspace for a long time (5 months to be exact), but just today this error started occuring.
It occurs even for a simple Java main which just outputs a string.
I've restarted my PC and even tried the steps here again restarted but still getting this "CreateProcess error=1450, Insufficient system resources exist to complete the requested service".
Has anyone encountered this and how did you fix it?
Heading ##
Really unsure what happened, but for the meantime, I replaced the jdk-10 folder with a freshly downloaded jdk 10 from Oracle.
One thing I did notice is that the old jdk-10 was:
Wheres the fresh download was:
I still don't understand why it worked for 5 months and only today that it became broken...
On all four of my Windows 7 x64 Pro computers with Visio Pro 2010 installed, I have had the following problem for the past several months: When I edit a Visio document that uses the UML stencil, as soon as I try to edit any object information, for example, define a table column, Visio locks up. By ‘lock up’, the program ceases to respond, Task Manager shows that the process is consuming 13% of the CPU, and the process has to be terminated via Task Manager.
In an attempt to resolve this problem, I had tried repairing the installation and uninstalling/reinstalling the program, but this has not resolved the problem.
I recently attached Visual Studio to the process to try to better understand the issue. As expected, there were numerous messages of the type ‘Cannot find or open the PDB file.’ The messages which, I sense, may be relevant were as follows:
First-chance exception at 0x7713C54F (KernelBase.dll) in VISIO.EXE: 0x80040155: Interface not registered.
In an attempt to address this issues, I tried:
C:\>regsvr32 c:\Windows\system32\KernelBase.dll
This resulted in a popup window with the following message:
The module “C:\Windows\system32\KernelBase.dll” was loaded but the entry-point DllRegisterServer was not found.
Make sure that “C:\Windows\system32\KernelBase.dll” is a valid DLL or OCX file then try again.
The version of kernelBase.cll that is currently installed is 6.1.7601.24214, dated 1 Aug 2018 with a size of 419,840 bytes.
I used MultiFind Pro to search C:\Windows for any files named KernelBase and found quite a few older version in C:\Windows\winsxs. There were also numerous folder of the type C:\Windows\winsxs\amd64_microsoft-windows-kernelbase_[identifier]. As well as other, similar folders. (What I am finding very strange is that MultiFind Pro is reporting a different file size and date than Windows Explorer or the Windows command prompt DIR command for all versions of this file.)
The last time a Visio UML file was successfully edited was Dec 2017 and based on the modified dates of the files found, the last version of KernelBase that was known to work was version 6.1.7601.23418, dated 18 Jun 2016.
I am fairly certain that my computer does not have a virus. I also know that reinstalling Windows will not resolve the issue as I have the same issue across all of my computers.
If I were to try copying Kernelbase.ddl V6.1.7601.23418 from the winsxs ‘backup’ folder, would it simply get over-written by the newer versions?
More importantly, can anyone suggest a specific course of action to resolve this problem?
Nikolay - I assume you are the MS Engineer who helped me with this issue - thanks.
Without boring everyone with the details: The problem occurs when my password manager, Sticky Password, is also running. Shut it down, and Visio works just fine. I have alerted the company and have asked them to fix the problem.
After upgrading to the latest version of MySQL Workbench(6.3.9), I receive a Microsoft Visual C++ Runtime Library error dialog window displaying the following image:
Assert dialog window
This happens about 3-4 times a day. Any known solutions?
This bugged me so I investigated and luckily I found a solution that worked for me.
On windows:
Go to %appdata%\MySQL\Workbench\sql_history. There are files in this folder with date in yyyy-mm-dd as the format of the name.
One single file here is very large in relation to the other files, for me its the earliest date. I deleted this file and have not seen the issue since. Back it up first if you to keep your history for reference.
I'm trying to install Netbeans 8.2 Java EE, but whenever I start the installer it quits after configuring it. I am trying to install it on Windows 10 64-bit.
This is not going to make sense at all, but do you happen to have the "God Mode" item on your desktop? Take it off the desktop (delete it, move it somewhere else, whatever). I have no idea why, but it worked for me: I found the solution in this bug report - https://netbeans.org/bugzilla/show_bug.cgi?id=269988
I do hope this helps you, too.
This is an Java issue, which was came up due to recent windows 10 update, that started treated differently for GodMode folder/shortcut.
This has been already fixed - https://bugs.openjdk.java.net/browse/JDK-8179014
You can verify the fix in early access build of JDK8 update 152, which is available here
We have verified the issue only with GodMode, do let us k now if there are any other scenarios that can cause such similar issues.
I'm adding this because: I had a different issue which I was unable to find addressed anywhere, this question appears near the top of a web search for "NetBeans 8.2 ee won't install on Windows 10", and someone else may have the problem I had.
My NetBeans install was almost immediately crashing with the following error:
An unexpected exception happened in thread main
Exception: javax.xml.parsers.FactoryConfigurationError: Provider for
class javax.xml.parsers.DocumentBuilderFactory cannot be created
In my Windows 10 System Properties -> Environment Variables -> System Variables, I had a previously created _JAVA_OPTIONS variable values using -Xbootclasspath/a to append some jar files to the end of the bootstrap class path. These files are used with some work I'm doing with the Oracle BI Publisher plug-in for Microsoft Word.
As soon as I renamed the _JAVA_OPTIONS variable to something else, my NetBeans installation started normally and completed with no issues.
After NetBeans installation, I reset the name of this variable back to _JAVA_OPTIONS, and discovered that the values I have for this System Variable cause NetBeans launch to crash. (Which does not completely make sense to me since I am only appending these files/classes to the class path, and not overwriting.)
Regardless, I'll have to go back to the drawing board for my work with the BI Publisher plug-in; but at least I can use NetBeans now!
Uninstall any Java installations along with NetBeans, and install Java with NetBeans (bundle) from the Oracle website.
I had the same issue, and then installed the bundle, works perfectly.
I'm using install4j and it works fine for the 10 languages we've got translations for, however if a user tries to install on a (windows XP) machine that's using another language eg Russian or Estonian, then an error.log file is created in the directory containing the installer. The installation completes without any apparent problems and gives a choice of language to run in but also creates the error log.
Am I doing something wrong? Or can I suppress the error?
Is this fixed in later versions of install4j (I couldn't see any mention in the change logs and it's non-trivial to ask for our build machine's install4j to be upgraded)
Is there already an open install4j bug?
Do I need to collect more diagnostics?
any ideas?
Recreation Steps:
Control Panel-> Regional & language settings-> Regional Options-> Standards & Formats-> Estonian
Run Installer
Error.log then contains:
java.lang.NoClassDefFoundError: sun.awt.AppContext$PostShutdownEventRunnable
at sun.awt.AppContext.stopEventDispatchThreads(AppContext.java:535)
at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:296)
at java.lang.Thread.run(Thread.java:736)
java.lang.NoClassDefFoundError: java.nio.charset.Charset$3
at java.nio.charset.Charset.probeExtendedProvider(Charset.java:397)
at java.nio.charset.Charset.lookupExtendedCharset(Charset.java:420)
at java.nio.charset.Charset.lookup2(Charset.java:454)
at java.nio.charset.Charset.lookup(Charset.java:440)
at java.nio.charset.Charset.isSupported(Charset.java:486)
at sun.nio.cs.StreamEncoder.forOutputStreamWriter(StreamEncoder.java:79)
at java.io.OutputStreamWriter.<init>(OutputStreamWriter.java:91)
at com.exe4j.runtime.util.WinDel.scheduleDeletion(Unknown Source)
at com.exe4j.runtime.WinLauncher$3.run(Unknown Source)
The error.log is actually not from the installer process but from a cleanup process that is launched when the installer exits. The cleanup process deletes the temporary directory to which the installer has been extracted. Due to this exception, that temporary directory has probably not been deleted. The integrity of the installation has not been impacted.
Interestingly, this error can only happen if the encoding "UTF-16LE" is not available in the JRE. However, this is one of the basic encodings that have to be available. So it looks like there's a bug in the JRE that is triggered in this specific situation.