Announcement: MapTool 1.5.1 Released

[Phergus]

This is what I would do.

• Uninstall all JDKs and JREs.
• Make sure all JDKs and JREs are removed from Program Files & Program Files x86
• Make sure C:\Program Files (x86)\Common Files\Oracle\Java is deleted
• Make sure any java*.exe in C:\Windows\System32 or C:\Windows\SysWOW64 are removed
• Make sure any reference to Java anything is removed from both user path and system path environment variables.
• Reboot
• Reinstall any Java versions required. Note that MT versions 1.3b91 and forward work just fine with Java 10.0.1.
• Reboot

[Full Bleed]

This is what I would do.

• Uninstall all JDKs and JREs.
• Make sure all JDKs and JREs are removed from Program Files & Program Files x86
• Make sure C:\Program Files (x86)\Common Files\Oracle\Java is deleted
• Make sure any java*.exe in C:\Windows\System32 or C:\Windows\SysWOW64 are removed
• Make sure any reference to Java anything is removed from both user path and system path environment variables.
• Reboot
• Reinstall any Java versions required. Note that MT versions 1.3b91 and forward work just fine with Java 10.0.1.
• Reboot

I've done all of that and more... spent *hours* on it. Rebooted and reinstalled everything dozens of times (in various locations.) Used CC cleaner. Used Oracle's removal tools. Hand-scraped my registry (this was a last ditch attempt to find something problematic.) I have no java on my system but 10.0.2 now.

Maybe I've got something on my system protecting some setting or path data from being assigned during install... my primary protections are Defender, WinPatrol Plus, and Malwarebytes. But I'm sure I've run some one-offs over the years, too, to address some lesser know security threats.

But I still have concerns about the assertion that:

So, the "install" doesn't even come with java.exe or javaw.exe but rather dll's which are/can only be used by MapTool.exe (which is a security thang) so nothing else on your system can technically run a java jar using what we package with MapTool.

I don't know what to tell you. If I uninstall 10.0.2 MT 1.5.1 will not run on my system. Neither the JAR (obviously) or the EXE install. The only way I can get the EXE version of MT 1.5.1 to run (which has the non-greyed out Startup tab) is if I have manually installed 10.0.2 with the manually added 64 bit environmental variable path (otherwise I think its tries to utilize the 32 bit path and fails out with the default 4gig mem config.) So it's obviously *using* my 10.0.2 install (even if Gather Debug has a display bug) over its self-contained install because it fails out the moment I uninstall 10.0.2.

Trust me, I'd rather not have an abandoned and insecure 10.0.2 installed on my system. I'll lock it down best I can (short of running everything in a VM), but I would not choose to run it this way if I had any other choice.

[taustinoc]

I don't know of any easy way to turn of Defender, but it seems exceedingly unlikely that Defender is the problem and you're not aware of it. I certainly didn't have any problems with it.

is there an easy way to turn off the other security software for the duration of the install? (And maybe run the installer as admin while you're at it.)

[Phergus]

That's frickin weird. Really stretching but check in your user directory under .maptool/config and .maptool-rptools/config. If there is a launch.properties file, rename it in case it is somehow reading that and getting a bogus Java dir from it.

Might also check the logs/log.txt files and see if anything interesting shows up there.

Under your MT 1.5.1 install check the runtime directory. It should have these stats:

Screenshot 2019-03-25 13.54.30.png (18.92 KiB) Viewed 2334 times

In the app directory is a MapTool.cfg file. Check for anything unusual there.

The main install directory has 50 files totaling 5.73 MB

[Azhrei]

I'm in no position to know what's different about your system compared to everyone else's. None of us here are. All we can do is keeping taking stabs at it until something makes a difference.

Phergus had something for you to check, but another thing to try is creating a new user on the system and installing under that user. (Minimize weirdness as much as possible: no spaces or punctuation characters in the username, for example.) I've found that to be helpful on other systems as it eliminates all of the customization that's been done to the primary account. (Having said that, when the other account worked, it was still a major PITN to figure out what was different about my main account that was screwing things up, but at least the issue had been narrowed down.)

[Full Bleed]

That's frickin weird. Really stretching but check in your user directory under .maptool/config and .maptool-rptools/config. If there is a launch.properties file, rename it in case it is somehow reading that and getting a bogus Java dir from it.

Only thing under .maptool-rptools/config is a layout.dat file. I don't have a .maptool/config directory... maybe because this last install I did to my desktop.

Might also check the logs/log.txt files and see if anything interesting shows up there.

Nothing interesting in the log.txt file.

Under your MT 1.5.1 install check the runtime directory. It should have these stats:

Same.

In the app directory is a MapTool.cfg file. Check for anything unusual there.

Code: Select all

[Application]
app.name=MapTool
app.version=1.5.1
app.preferences.id=net/rptools/maptool/client
app.runtime=$APPDIR\runtime
app.identifier=net.rptools.maptool.client
app.classpath=
app.application.instance=multiple
app.mainclass=net/rptools/maptool/client/LaunchInstructions
app.mainjar=MapTool-1.5.1.jar
packager.java.version=10.0.1

[JVMOptions]

[JVMUserOptions]
-DMAPTOOL_DATADIR\==.maptool-rptools
-Dfile.encoding\==UTF-8
-Xss=4M

[ArgOptions]

The main install directory has 50 files totaling 5.73 MB

Same.

To respond to other ideas:

1) Have tried running the install as administrator in various permutations. Made no difference.
2) Have not tried installing without my other security apps... They've never interfered with anything else (without letting me know that they were) so I didn't bother... I may get around to test that though. But, in general, when people are told to turn off their system protections I cringe. They're there for a reason.
3) Create a new user account. I thought about this, too. I suspect it will work (seeing as how I was able to install mt 1.5.1 fine on other computers in house)... but, as mentioned, I'm not sure it's going to help me find what the corner case is here. For giggles I might just try it though...

[Full Bleed]

but another thing to try is creating a new user on the system and installing under that user. (Minimize weirdness as much as possible: no spaces or punctuation characters in the username, for example.) I've found that to be helpful on other systems as it eliminates all of the customization that's been done to the primary account. (Having said that, when the other account worked, it was still a major PITN to figure out what was different about my main account that was screwing things up, but at least the issue had been narrowed down.)

So, as expected, running the exe under a new user account did work.

But it threw this error when checking the Debug info:

MT Java Version error.jpg (37.94 KiB) Viewed 2311 times

On another computer that I removed Java 8 from before install, I didn't get that. But I did see this text in the debug:

==== Java Information ====
Java Vendor.: Oracle Corporation
Java Home...: C:\Users\xxxx\Desktop\MapTool\runtime
Java Version: 10.0.1
Result of executing 'java -version':
............: Error: could not find java.dll
............: Error: Could not find Java SE Runtime Environment.

[Azhrei]

Yep, so a problem with the user configuration. At least it's narrowed down to something related to that account. I know — it doesn't narrow it down by much.

As pointed out previously, you can ignore the "java -version" output. It's meaningless for anything other than running the JAR directly (we're taking it out of the next build entirely).

[Full Bleed]

Yep, so a problem with the user configuration. At least it's narrowed down to something related to that account. I know — it doesn't narrow it down by much.

I'm still not sure how the user configuration somehow manages to make/allow the MT EXE install to use an external Java install... *shrug* But if you guys aren't worried about it I won't worry about it.

I was hoping I could narrow it down to help others. I suspect that most will simply be more than likely to just default to the JAR method (like the user in the other thread.) I'll be sticking with the JAR myself now that I've worked out how to get my bat to work.

Regardless, one thing all this testing has done is make me appreciate the nice uninstall on this build. So many programs do such a horrible job of properly uninstalling... leaving all kinds of legacy behind.

As pointed out previously, you can ignore the "java -version" output. It's meaningless for anything other than running the JAR directly (we're taking it out of the next build entirely).

Understood. What I found more curious was the differences in error reporting.

[Phergus]

I'm still not sure how the user configuration somehow manages to make/allow the MT EXE install to use an external Java install...

It isn't. MapTool is being launched with the JVM installed with it but something else about your configuration is changing - probably being fixed - when you do have a JRE installed.

Understood. What I found more curious was the differences in error reporting.

Code: Select all

Result of executing 'java -version':
............: Error: could not find java.dll
............: Error: Could not find Java SE Runtime Environment. 

That is disturbing as it means you have a java.exe file somewhere in your path and it is complaining that it can't the java libraries. So you have a broken java install on that computer. The JRE inside the MT install directory is not in the general system path and isn't available to it. It doesn't have a java.exe file.

The exception shown in your screen grab is expected if that system does not have a JRE/JDK installed. As Azhrei said, this check is now superfluous and has been removed.

Thanks for continuing to check into this. With luck we'll find out what the root cause is here.

[Full Bleed]

Code: Select all

Result of executing 'java -version':
............: Error: could not find java.dll
............: Error: Could not find Java SE Runtime Environment. 

That is disturbing as it means you have a java.exe file somewhere in your path and it is complaining that it can't the java libraries. So you have a broken java install on that computer. The JRE inside the MT install directory is not in the general system path and isn't available to it. It doesn't have a java.exe file.

Jamz and Az have indicated that was related to an MT Gather Debug bug. I'm seeing this on multiple computers and new user accounts that launch 1.5.1 without a secondary Java install. Have you tried removing Java from your system and only using the MT EXE install? I don't think the above "error" is all that relevant aside from the fact that it's looking/reporting the wrong thing (i.e. if it's looking at the included Java install version it probably has to pull that info differently.) So, again, I was just pointing out that the "error" is slightly different in new user accounts that have never had Java installed and working accounts that have (but have removed it.) Same basic bug, but different reporting.

[Phergus]

Jamz and Az have indicated that was related to an MT Gather Debug bug.

They are mistaken.

Code: Select all

Result of executing 'java -version':
............: Error: could not find java.dll 
............: Error: Could not find Java SE Runtime Environment.

As I told you before, you can only get this if there is a java executable somewhere on your system. If you uninstalled Java you needed to reboot afterwards. You also have to manually remove this entry from your system path:

Code: Select all

C:\Program Files (x86)\Common Files\Oracle\Java\javapath;

It wouldn't hurt to remove the Oracle\Java directory entirely.
Then reboot.

Have you tried removing Java from your system and only using the MT EXE install?

I have a Windows 10 laptop that does not have a JRE or JDK on it. MapTool 1.5.0 installs and runs perfectly. If you do a Gather Debug Information on a machine that truly does not have Java on it you get this:

Screenshot 2019-03-26 15.39.38.png (32.03 KiB) Viewed 2192 times

[Azhrei]

Jamz and Az have indicated that was related to an MT Gather Debug bug.

Heh-heh.

We're talking about two different things. Jamz and I are saying that the Gather Debug Info shouldn't be executing that command at all because it's no longer relevant (and in fact, is gone from 152-beta).

Phergus is saying that because it does run but fails to find the DLLs that it needs, you've got a broken installation of Java somewhere on your system.

We're both correct, just talking about different things.

Phergus' point is well-taken in that a broken Java installation could be causing other problems (and likely is). You have to remember that Windows is pretty stupid about DLLs. If you've got JAVA.DLL in directory A and another one in directory B, whichever one is listed first in PATH will be picked up if an application requests it. So an application (like MT) that is in directory B could pick up the (broken) DLL in directory A.

The truly stupid thing is that there is no way to prevent this on Windows if the DLL is already in memory, because Windows checks the list of in-memory DLLs before it ever starts looking on the disk. (See here if you want it straight from the horse's mouth; I simplified a bit, above.)

This is one of many reasons why rebooting is so important — it's about the only way to clear that cache. (I think there are commands now that can do it, but I've never looked because, tbh, I don't care. Windows is too opaque an operating system to effectively diagnose problems; it just devolves into "try this" and "try that", because there's no transparency into how things actually work. It sucks for users, that's for sure. If you feel up to it, there's a tool that can monitor which DLLs an application loads. You could run the tool against MT and see if it's loading a DLL from a strange directory that wasn't part of the installation: Go here and scroll to the bottom.)

I'm seeing this on multiple computers and new user accounts that launch 1.5.1 without a secondary Java install.

What is the "this" that you're referring to? Is it that the java -version executes but fails with an error about a missing DLL, or is it that MT 151 flashes the screen and dies immediately?

[Full Bleed]

What is the "this" that you're referring to? Is it that the java -version executes but fails with an error about a missing DLL, or is it that MT 151 flashes the screen and dies immediately?

The *this* I'm referring to is this in Gather debug (so MT is running):

Result of executing 'java -version':
............: Error: could not find java.dll
............: Error: Could not find Java SE Runtime Environment.

...that Phergus is indicating is a problem on my side. I do not believe this is unique to me. I've tested on 3 different systems that have "removed" java prior to using the 1.5.1 MT EXE install. Each one throws that message in Gather debug. In each of those cases MT is loading. It's working. But GDB is showing that error. On an account or system that *truly* has never installed Java you get the other pop-up exception error.

This is one of many reasons why rebooting is so important

I always do after Java un/installs. Though, to be honest, if it were absolutely necessary Oracle should have flagged their un/install for that. There are options when uninstalling things "properly" in windows where the developers can have windows prompt, warn, or demand that a reboot is necessary. Java installs do none of those things... and, further, they leave all kinds of legacy data behind (registry entries, directories, and files.) If my issue is because of this, it's likely their sloppiness over the years that's caused the problem. Heck, I was finding stuff from 1.6 in my registry (though none of it looked material.)

You could run the tool against MT and see if it's loading a DLL from a strange directory that wasn't part of the installation: Go here and scroll to the bottom.)

Thanks. If I try this I'll let you know.

Unfortunately, I rolled back my primary test system (with my initial issue) a week after I couldn't generate an External Address via "Connection Information" inside MT... thinking I might have broken something with all this "testing". Turns out MT needs the RPTools Registry for that? Ugh. Can't MT pull that locally? Kind of a double whammy when people who can't start an alias server have to use a direct connection method that requires them to get their IP from some other source/method. I always use direct connection, but for those that don't it's an extra step to hunt down their IP for an unfamiliar process.

[taustinoc]

Unfortunately, I rolled back my primary test system (with my initial issue) a week after I couldn't generate an External Address via "Connection Information" inside MT... thinking I might have broken something with all this "testing". Turns out MT needs the RPTools Registry for that? Ugh. Can't MT pull that locally? Kind of a double whammy when people who can't start an alias server have to use a direct connection method that requires them to get their IP from some other source/method. I always use direct connection, but for those that don't it's an extra step to hunt down their IP for an unfamiliar process.

If you're behind a router (and nearly everyone is), the only practical way to find out your public IP address is to connect to somewhere else and as "what's my IP address?" The best way to do that is to control where you connect to. That's how MapTool is set up. There are other ways to do it, but none that are practical.