v11) "internal error" caused by "Logging = FALSE" (.vmx)

[RJRacey]

Starting in Workstation 11.0 - 11.1, any .VMX file containing the statement "logging = FALSE" triggers the infamous "internal error", preventing the guest from starting.  You used to be able to disable logging on all prior to versions.  This through me for a loop because the "internal error" popup doesn't exactly leave any clues as to where in the .VMX file contains a bad statement.

Yes, I know, it is highly recommended to leave logging enabled -- which this never would have happened because it would have been logged.  I suspect this to be a newly introduced bug assuming VMware did not actually intend to kill upward compatibility for existing guests.  But if cache folders aren't bad enough at cluttering up the guest folder, log files were one PITA you used to be able to turn off.  To the vast majority, the contents of log files are almost as meaningless as whatever's inside cache folders.  Whenever a guest stops working, go to a backup copy.  Simple.

Anyway, it would be nice to have this nuisance corrected in the next release if only to save time and aggravation for those upgrading to version 11, donating money to VMware corp. for the privilege.  Better still, if a toggle feature were added in VMware Workstation to clean up after itself, that would be a real treat too.  That way when backing up guest folders, not having to constantly delete garbage files avoids the risk of inadvertently deleting a wrong file.

[dariusd]

Hi RJRacey,

I can't reproduce the problem you describe here... logging = "FALSE" seems to do exactly what it is supposed to do.  I forwarded your post to our logging developers and they have reported likewise.

Can you perhaps provide (as a file attachment) the .vmx file which is triggering the Internal error?  Also please let us know which operating system you are running on the host.  Did the exact same .vmx file work correctly with an earlier version of Workstation (or Fusion or ESXi)?  If so, which version(s)?

Cheers,

--

Darius

[RJRacey]

This was the case with a half dozen guest OS's -- from w2k to Vista.  The "internal error" effect was clear and unmistakable, and for me, completely reproducible -- like night and day.  I duplicated it on two different hosts (both 8.1), which struck the first guest after Workstation 11.1 was installed.

This one single statement "logging = FALSE" (verbatim) that has worked flawlessly in every version of Workstation, from 10.x all the way back to version 6.x, croaks in 11.1.  I could send you before and after samples of a .VMX file, but the only difference is the presence of this single "logging = FALSE" statement.  As I said, my .VMX files vary for different guest OS's, including one that vCenter Converter just created for me yesterday.  I never touched the .VMX file until I added the statement to the end, and that is when the "internal error" struck and refused to launch.  Since that was the last thing I did, I simple removed the line and the guest worked again.

That is how I was able to catch the culprit; otherwise I'd still be pulling out my hair.  Or more likely, given up and fell back to version 10.x.

[dariusd]

Please provide (as an attachment to a reply) one of the .vmx files which triggers the failure.  We are still not able to reproduce the failure here.

Thanks,

--

Darius

[RJRacey]

Here are two .VMX files that cause WS 11.1 to generate an "internal error" on startup, and would only work with the line "logging = FALSE" removed.  This happened on two 8.1 hosts after upgrading from 10.x to 11.1.

"racey2.vmx" is a freshly converted Vista machine.  The "Windows 2000 Professional.vmx" is an old W2K guest I've had around for years, that has seen various versions of VMware all the way back to 4.x I believe.

- Russ

[dariusd]

Interesting... I can power on both of those .vmx files (when I attach a blank .vmdk to each) and they work just fine.  Ironically, a logfile might help diagnose the problem... Could you possibly attach a vmware.log from when you power on the VM *without* the logging = FALSE option present?  Also, check to see whether any dumpfiles (*.dmp) are being created when the "Internal error" occurs.

Thanks,

--

Darius

[continuum]

With current Workstation-versions I would regard the idea to disable logfiles as a really bad idea - not as bad as active sabotage - but close to it.
Why dont you instead use
log.keepOld = "1"

One log would still enable you to recreate the vmx and vmdk descriptorfiles if that ever becomes necessary.

I would have no objections at all if you instead disable Unity to get rid of those cache directories.

The 2k VM boots nicely hear - although you do not use the correct syntax as far as I know.
I would use
logging = "FALSE"

[RJRacey]

"Ironic" is right.  Couldn't have said it better.

Attached are log files from the W2K guest I recently ran (without the logging statement).  Not sure what they'll indicate since the machine appeared to run normal in all respects (except for the initial disappearing Shared Folders created by the new version of VMware tools -- separate issue).  I didn't find, or rather, didn't notice any .dmp files left in the root folder of the guest after it croaked with "internal error".

Mind you it happened so fast, I doubt the parsing of .vmx was even complete.  Cylon logic bombs work slowly; this one is instantaneous.  😉  Wasn't aware you could launch an .vmx without any of the other files.  Perhaps you need to run an actual guest to reproduce the problem.  I only know I can reproduce it here by simply adding that line back in.  I'd send you a copy of the entire guest folder if it wasn't GB's.

[RJRacey]

Pearls of wisdom to be sure - leaving logging enabled.  I am a self-confessed lazy-SOB who can't stand cryptic files cluttering up my disk.  But I'll be sure to give "log.keepOld = "1"" a try to see what it does in WS 11.

  One thing you mentioned caught my eye:  Turning off unity eliminates cache folders??  I had no idea the two were connected; never had much use for Unity anyway.  Where do I do that pray tell?  In my VM Options tab all I see ticked is "Show borders", "Show badges" and "Enable applications menu".  Nothing that disables Unity altogether.  Is that done by a .VMX statement?

[continuum]

Right after posting I realized that I have not tried those parameters since 2 or 3 years. I dont know if they still do what they did in WS 8 and 9.
I need to look it up. If I remember right I should have them explained either on sanbarrow.com or ....

found it: VMware Continuum - Unity

please try and report if it still works.
iI never use shared-folders - eventually the cache-dirs are also needed for "shared folders" or "copy and paste" into a VM.

And of course those tweaks that can affect an advertised function all go into the vmx-file.
Only the idiot-proof options and the most dangerous ones will make it injto the GUI :smileycool:

[dariusd]

From the symptoms you are describing, the .vmx file alone should be sufficient to run an "empty" VM in a configuration suitable to reproduce the failure.  It's bizarre that no-one else is able to reproduce the problem...

The VMware Workstation user interface keeps a UI logfile that might also help.  It should be somewhere inside your %TEMP% folder... Apparently the Help > About VMware Workstation box might give you the UI log file path.  (Sorry, I'm not a Windows person, I'm nowhere near any Windows machine to check the exact path, and my KB search-fu seems to be escaping me right now too...).

If you can find the UI log, please grab it right after the "internal error" shows up, attach it here and I'll take a peek.

Cheers,

--

Darius

[RJRacey]

Attempting to disable unity by adding these lines apparently no longer works.  WS complains the .VMX is corrupt and opens a blank window.

unity.enableLaunchMenu = “FALSE”

unity.showBadges = “FALSE”

unity.showBorders = “FALSE”

unity.wasCapable = “FALSE”

Nice idea ... wish it still worked.

[RJRacey]

YOU WERE RIGHT!!  Syntax.  Staring me right in the face.  All this time, the syntax of this statement has been wrong in my .VMX files.

All my original .VMX's had (pasted in from some forum thread years ago😞

logging = FALSE

instead of:

logging = "FALSE"

Missing quotation marks ("") around the boolean argument.  Damn!  For some reason, all previous versions of WS let this pass.  Apparently WS 11's parsing of .VMX must have been revamped to reject such sloppyness.  Though it ought to have done so in a little more graceful manner than simply throw up an "internal error" leaving no clues.  I wonder how many such errant statements are imbedded in .VMX files that are suddenly flagged this way, perhaps creating the same "internal error" response leaving the user bewildered as to what caused it.

One thing I noticed, that if you use the wrong quotation characters -- “ ” instead of " " -- as in example: logging = “FALSE” , WS 11 catches this more gracefully by popping up a warning tooltip, changes the logging parameter to TRUE (default), proceeds running the guest and logs what it did.

So logging can be turned off after all, if you observe strict .VMX syntax.  I only wish the same could be done for those pesky cache folders.  I kinda miss version 6.x. 

[RJRacey]

Whoops ... premature.  For some reason adding quotation marks seemed to work a couple of times.  Then it didn't.  Same thing with other guests I tried.  So my earlier assertion that "logging = "FALSE"" triggers an "internal error" still stands.  So in the meantime, I'm gonna give "log.keepOld = "1"" a try -- not exactly sure what it does, but if it reduces the number of log files generated, good.

Something is definitely fishy with the way WS 11 parses .VMX.

[dariusd]

Our testing here was done with your .vmx files directly -- we did not reprocess them at all or edit them before powering on the virtual machines.

Any chance you could find the UI log mentioned in my other post in this thread?

Cheers,

--

Darius

[dariusd]

Ah... I just found the bug!  It will manifest quite unpredictably, which is why we were unable to reproduce it here.  RJRacey, your system is clearly hitting just the right conditions to bring out the issue.

I'll pass it over to our logging folks and we'll see about getting it fixed.

Thanks for reporting the issue and working with us to get to the bottom of it, and sorry for the hassle it's caused!

--

Darius

[dariusd]

Hi again RJRacey,

This problem should be resolved in Workstation 11.1.2, released a few weeks ago, although it is not mentioned in the release notes... It would seem we overlooked this one when putting the release notes together.

If you've updated to 11.1.2, please try removing the logging = "FALSE" option and let us know if you continue to encounter any problems.

Thanks!

--

Darius