RaSystemlord's Posts

@Orkide15  OK, thanks for letting everybody know   This was something that I didn't expect at all. Based on your description, it doesn't work, if you use something else than the default folder. Obviously, this is a software installation bug, but not something that I have confronted. I can only speculate on the source of the problem, but: Typically, the installation folder is stored in the registry. Every part of the software uses that location, but now in this case something in the software does NOT read the location from registry, but uses a default folder (which should never be done). This kind of makes sense that licensing key check, makes this error - if something does, I think.

The analysis of this problem, providing that all is correct that has been said before, would be something like this. This is of course speculative, but this explains why my questions. Further info might also solve the case immediately. I leave out the trivial choices that would also solve the case (like Windows 10 Upgrade or errors when installing or old 16.x version) - some of these have already been discussed in this thread, but not answered. Since the same problem was with an older version of VMware and because this also indicates an older version of Windows 10 being used, this is something typical for this particular system or the user case. The immediate choices would be like the following: - Administrator rights are not real Windows rights. This can easily be the case on a corporate PC - this is already asked but not answered - wording suggests that the computer has stayed the same. Thus same programs are probably run. This give multiple choices: a) Some 3rd Party security software is preventing VMware licensing to write (perhaps to registry or somewhere else). This can be a hidden program on a corporate PC OR virus scanner that does much more than is anticipated (works as a firewall) OR misconfiguration of such a program - this item as a whole was asked before b) Some other application has blocked the write to the registry. This isn't very likely to happen with mainstream applications but with misc & beta applications this can happen - this item as a whole was already mentioned with the request to study especially Event Viewer c) Some other application has done something else to prevent VMware Player to start correctly. Those include rather difficult to find problems - environment PATH messed up with new entries or wrong order of entries OR various .dll problems - these possibilities are also included in the request to study Event Viewer and log files in "temp" (system and user) - things that are now ruled out based on the questions: a) Windows installer compatibility, since System is updated, b) bad download of VMware since this problem has been repeating with different versions, c) wrong way of installing since this has been once corrected (most likely with something else than the install itself)   If somebody has already some time in the past, had this problem and solved it, does these lists ring any bell?

@Orkide15  I understand very well what your problem is. What I meant was that your Windows system behavior is not what happens by default in Windows. I'm using CLEAN Windows 10 systems to test these and I can very well see the abnormality in a correctly working system compared to your system which doesn't work correctly - thus it is working wrong. This is just normal English, nothing personal, nothing sinister. As a personal OPINION, when software installation on a Windows system is not working correctly, there is something very wrong, somewhere. This kind of "wrong" can happen because of VERY many reasons. I already asked about a few very obvious candidates for this - twice, but no anwers. Event log and "temp logs" was already mentioned above. Those are the tools of the trade to get hang on the problem. I could easily add many more reasons, like 3rd Party security software of many kinds. But there is no point in analysing further, if nothing is answered. If you find a solution somewhere that works, without doing further analysis of your system, let us know - that is the idea on this discussion Forum. The idea here is also that if somebody cannot give you an answer, you wait if somebody else has a better idea. There isn't much point in messing with those who try to solve your case.

@Orkide15  This wasn't solved in the above. There is something wrong in your Windows in terms of administrating it. This isn't normal behavior for Windows 10. The questions are thus the same as above. In addition, have you run Windows Updates after VMware installation, especially run a Feature Upgrade. If you have, reinstall VMware that might solve the case (in this particular scenario). Use the latest version 16 since you have rather latest Windows 10 now.

It may well be a processor compatibility issue (combined with VMware version compatibility). I tried to Google for it, but the links for Compatibility Matrix don't seem to work now. There have been some recent posts where this processor vs. Win98 -thing was discussed - maybe those would help you to find the core reason?

Do you have two network adapters in your Host? If you do, I think the solution would be to create a new networking of your own and connect that to the other network adapter. I don't think that VMware tries to do automatically networking for multiple cards. The method was explained already in my previous post.

I assume, but not sure, that this is about an incompatibility with newer VMware versions and Windows 98. However, in generic, for .dll problems, you might try to actually harvest a missing .dll from somewhere (typically Google will help you), place it in the correct location and perhaps register it, if required. Just make sure that you don't get a bad .dll and install that (non-working, too old, infested, whatever). This solution, I would describe as the last straw, if you don't get better choices from somewhere else.

Thanks for the clarifications. As explained above in length, the physical card on the physical computer has to work, but that is not what you contemplate when trying to find out why it doesn't work in a VM computer. After installing VMware at Ubuntu 18.04 (did you use .bundle from VMware Site or something else?), do you see vmnet1 and vmnet8 VMware networks on Ubuntu? If not, there should have been warnings when installing. (command "ifconfig", not sure if that particular *buntu version has that by default, but it will tell what package to load in order to get that utility). If that is OK, VM computer Settings will have a place, where you select what kind of networking you want to have (Bridged, NAT, Host-only). I think NAT is the default. Do you see that? Finally, do you see networks in your Guest? If not, you can create your own and test why it fails. In order to do that in GUI, you would need to install evaluation version of VMware Workstation Pro, which has this GUI, it will also install Player. When evaluation period of Pro ends, the GUI will remain operational. If the above was all correct - not sure, but install of VMware Tools might help in some situations. From previous posts on this Forum, it seems that there are users for CENTOS with VMware Workstation 16 - so there shouldn't be a reason why it fails. Or if it does, there should be a log file or announcement somewhere if the VMware installation wasn't successful. So, you need to go through the steps above and let us know, where exactly it fails (and how it fails ... you are now talking about a Host physical device connection failing, which doesn't really mean anything concrete in this analysis).

The technology is explained above. If you mean that you cannot get networking to work on your VM, there are several questions to you: - did the install of network adapters work, when you installed Player? - what is your Host and what is your Guest? (OS's and their versions) - what kind of networking you are trying to achieve? If the above is OK, then NAT networking usually works by default. If you try to use Bridged, that is dependent on many factories how successful you are. Basically, manual configuration may be required in certain circumstances (=if automatic didn't work) ... which configuration is no different than on a physical computer on that particular OS - if you have Host-only networking, network to the outside world is not even supposed to be functional There are many more possibilities that you might mean. Let us know.

This is a bit strange, providing that you didn't do a reboot in the process, which very well can change things? It is not self-evident that uninstalling any application can fix the system. It is possible, but only cases - that I can think of - which would allow this to happen would be: - VMware uninstall restores old .dll's (or similar system files, I refer them only with .dll in the following). This is rather uncommon to happen, especially without any user interaction - VMware installs a competing .dll that is used also by Outlook when VMware is installed. Dealing with such an issue, would require to inspect the system and first find the .dll in question. Then you would need to figure out what to do about it. In principle, either application has a mistake in their way of handling .dll's or their contents ... this should not happen - so that this wouldn't be that easy to study, you would need to pay attention to conventional .dll's and .Net .dll's which don't work the same way (fixed registering or auto-registering) - however, when this still happens, the most obvious reason for this is that, now that you have the new Windows 10 version in play, is either version NOT compatible with that Windows version? That would explain non-working dll's being installed and referred in the system. In principle, a new .dll should always work as well as the old one ... that is not true if the applications are not compatible with the overall architecture (the other explanation involves either software provider making a very big mistake by installing a non-compatible .dll with the same name) Just as a guess: VMware registers a .dll that is not compatible with Outlook. When you uninstall VMware, it deletes the registry entry and then Outlook can use some other .dll. Solution: Don't know, but perhaps update either software to a newer version, which is compatible or better compatible with your Windows version.

@Barry7  Yes, if this was indeed because of Windows Feature Update (which you did run), installing the application again, solves the issue. I have had some applications, which were corrupted EVERY time, when a CERTAIN Feature Update was done. If I remember right, this was between versions 18.03 and 18.09. But this is application-specific and this is Feature Update -specific when this happens. Your case could be very well a similar event. This is a rather intimidating problem if the reinstall takes lots of time. In my case, referred to above, I had to uninstall before a new install - but that is application specific and depends on what its install program is capable of. With MS Office 2016, not sure how it works, but I would try to run Repair first ... or then only the Outlook part of the uninstall/install if it lets to select installable modules (I know that some of the Office versions, don't let select anything by default when you first install them, not sure what you have there) or if that doesn't work, only Outlook+common parts ... and finally the whole bunch if nothing else works. I'm of course anticipating, based on your writing, that you might need to do this several times in your office and saving time might be very much desired.

Are you sure that you didn't have a Windows Feature Upgrade in between? I'm asking because this is a typical problem that happens when Feature Upgrade renders some applications to a non-working state. With Outlook, this happened with the very first releases of Windows 10. The solution, installing the application again, in this case Outlook, is the solution that makes the application to work. (This has to do with Windows Feature Upgrade moving everything to "windows.old" folder and then it doesn't always copy all the relevant parts of all the software to the new "windows" folder.) So, in this scenario, removing VMware was not necessary at all. Of course, this could be incompatibility between .dll's (or similar) with Outlook and VMware. In that case, I'm sure you will get advice directly from VMware.

@funk4food  Yeah, hard to say where the actual problem is. As I stated before, installing 21.04 failed on my particular physical system and thus I cannot test the scenario any closer. Candidates for the problem that you have: - Kubuntu 21.04 does not work very well with VMware. 21.04 is not a LTS-version and thus this could be more than just possible. However, it seems to have the same series of a kernel than Kubuntu 20.04 LTS, which does work ... which makes this choice more speculative - the matter than a 21.10 VM would cause problems to your Host, is also speculative. The idea is that this kind of transfer of a Guest problem would move to the Host, should in theory never happen. Still, we know that sometimes it is the case - random problem. Not sure what that random would be, a disk problem should not cause the symptoms that you have - your source for Kubuntu 21.04 system produces a different result. I always use .bundle from VMware Site. By the way, I did not install any VMware Tools for my 21.10 Guest, because everything, including window resizing worked just fine without any Tools ... this is not the case always, but with Kubuntu 20.04.02 Host this seems to be the case normally. As a more far-fetched problem: - you have an incompatibility with your graphics card with Kubuntu 21.04 Host. That will cause problems all over the user interface, which you seem to have AND it does affect both Host and Guest. Actually, the latter is what I had initially with Kubuntu 20.04 on my system, which has a entry-level good, nVidia graphics card, but of course rather old. Kubuntu was just choosing automatically a wrong (closed) display driver - much too new to be supported by the card. Solution was to manually change the driver for an old, supported choice (which has automatically stayed to be used, so, no further problems). If I remember correctly, the right graphics driver version could be changed from the user interface of Kubuntu Settings, once you get it up and running without the too new a driver. Your experience using VirtualBox as an aid, doesn't really support this far-fetched problem scenario.

@ksio89  Thanks for the tip! Yeah, requiring TPM (secure boot and all that) makes no sense on a development build testing. EDIT: This script is targeted for Updating into the original version. Well, for a clean install, which is 100% my preferred choice on any system, it makes no difference. For testing, sure this might be useful. BUT The official Windows 11, English, ISO (as provided officially by Microsoft today) does not install on VMware Player ... none of the new requirements are met in my VMware or Host. The latest Beta did install from (UUP DUMP) ISO (as commented in length elsewhere by me).

You can always ask, this is the idea here. However, this is a Forum of (mostly) commercial software and we cannot discuss how to by-pass trial version restrictions of some other commercial software. With commercial software, the basic idea is that you pay for them. Since you are talking about old software, there is a very likely chance that you find Open Source software, which is much better than your old commercial software. If Windows doesn't provide it, try some Linux, like Kubuntu or Ubuntu. By default, you get and see much more software than with Windows. For instance, Ubuntu Studio has basically tens of different tools for all creative aspects (photography, video, music, players, writing, graphics) and many others can be downloaded. There are many more dedicated distros. Now that you already use VMware, there is no practical limit how many different systems you can try out.

Implicitly, you assume that somebody else than Microsoft knows what Microsoft is doing October 5th with Windows 11. What I have personally read from the various IT News sources: - free upgrade from Windows 10 to Windows 11 comes much later, perhaps only next year, by mid-2022 per Microsoft announcement - commercial version that you can buy, may come out October 5th, or it is just published then What I know based on personal testing: - beta release series (commented in length in some other, very recent thread) works when installing from ISO, created with 3rd Party downloader & iso creator, works without specific hardware limitations. Beta Releases require that you join Insider Group. - development series, does not work if hardware requirements are not met. It is obscure, what they really are and what they really are in virtualization - if you install from ISO, it is obscure what Updates you don't get from Microsoft or How exactly you don't get them. Perhaps tomorrow we will know, but I doubt it Why would you use brand new Windows 11 to run older games (if that is what you wrote)? Why don't you use an older system, perhaps existing Windows 10 if they work there? You can always buy a new license for Windows 10 or Windows 11.   EDIT: Minor changes for clarity and this addition: Official version of Windows 11, English, Oct-5-2021, does not work on VMware when trying to install it from ISO. Hard to say why, but none of the new requirements are met on my Host and I haven't done anything to VM-computer firmware. Beta-release, when using 3rd Party UUP DUMP method, did install and work from ISO. I didn't try this 3rd Party method with the original version, because that wasn't yet available, yesterday (it usually takes a couple of days to arrive there). Windows Update into Win 11 wasn't available on my Win 10 computer. VM was part of Beta Insider Program, but trying to get rid of Beta Updates did not work, as explained by Microsoft. So, that installation seems to be ruined and a fresh Windows 10 installation would be needed to see, if Windows 11 Update arrives at some point - sooner than mid-2022, which is Microsoft announcement. However, that Update shouldn't work either on a non-supported hardware, but there is a patch for this. Microsoft has also announced that if you install from ISO, your hardware manufacturer guarantee will be void. For a software company to make such a groundless, but rather significant and costly threat ... I'm sure lots of theories will be presented (elsewhere), why that is - let us just say here, it doesn't make any sense from technical point of view. So, going back to your question: With Win 11 VMware use is completely stuck, at least for the Player, with the exception of Beta releases (not sure if they still work - they worked a few days ago with 3rd Party tools). In principle, owners of computers of win-11-non-supported-level, are being kicked off from Microsoft Insider Program - according to Microsoft - so, eventually nothing will work there either. Yet, again, something that makes no technological sense.

@funk4food  I have now installed Kubuntu 21.10 Beta (from Daily delivery source today), Updated it with the latest updates and installed Handbrake on it. Then I have ran Handbrake video conversion with 2 "processors" allocated to the VM for a few hours. Handbrake tries to take 100 % from both processors when it runs. I haven't seen any instability in this system. Host is LTS-version, Kubuntu 20.04.2 with latest updates. System has Asus Motherboard, i7 (2nd gen, I think), 16 GB RAM. My VMware Player isn't the very latest version, but is 16.1.0 build-17198959. I also tried to install Kubuntu 21.04, non-LTS, on a similar (EDIT:) PHYSICAL system (in principle, exactly same components). Installation didn't go anywhere, it stopped at kernel error collections. I double-checked with Kubuntu 20.04.02 installation and it proceeded just fine until the Live usage stage. This doesn't mean that 21.04 is faulty - perhaps some innocent incompatibility with something, which could be worked out. So - I let you do deduct from these results, what to do about it. If you have a spare SSD-disk, perhaps trying out with 20.04.02 Host for VMware would be a way to go forward? In principle, LTS-version is the more stable choice.

@binfitbox  OK, VPS is a Cloud Service. Basically, this is about what kind of contract you have with them. The issues are like these (probably not everything is mentioned in the below): - they probably have one virtual computer for each customer. Otherwise, security is not on a high level, if it must be - they probably don't even say what virtualization they use. It is THEIR business and they don't want to commit to a particular system, unless it is in your contract (which is doesn't seem to be based on your wording) - whether nested virtualization under their system works, is a question that you need to ask them and have in the contract - who is installing applications? If you have all the rights, who is correcting the situation if one of your applications breaks the system (in Windows, any application can break the system at any install, practically speaking)? What kind of ways you have to go back to the situation before the mishap? (You as a user-admin, do not have anything realistic in Windows - they might have, at least the VM backup from yesterday - but it needs to be in the contract). - how can you transfer the entire system back to you, if you can at all? Needs to be in the contract. What virtualization did they use in the first place - see above?   As for alternatives, if the above questions cannot be answered to your satisfaction by the VPS provider: - create a backup from your sophisticated application, when it is not in use. Use the application specific backup ... if it doesn't have one, you need to create it by yourself (depends largely on your DB system and files&stuff - it is doable, probably without too much effort, if you know your application well enough) - have a mirror system in your home VMware player. I mean, Windows installation which is about the same as your system in VPS ... it can never be exactly the same, if you cannot copy from their system. As I stated above, they might not let you to copy the entire system, it is a huge copy anyway (based on your writings, such a copy wouldn't be realistic at your connections), relatively speaking. If you really need to copy entire system across the network, make them use Bit Torrent delivery, to ensure that it really works - have that in contract (something like FTP is a 1970's tool). - have a folder called "delivery" (just as an example) where you store EVERYTHING that you installed on the VPS system. Thus you can easily redo ALL the installations, possibly on some other system. Please don't forget serial keys & instructions & misc stuff. - use your sophisticated backup from your application to install the same data into your home system, perhaps in 15 minutes or something This approach would be doable, would not require too much bandwidth and would be rather quick to do, providing that you do it once per week or something like that. Here you wouldn't be limited on what virtualization VPS has and what your contract mentions. Of course, since the replica would be in your Home VM, you could easily create copies from that and save many different states over the weeks and months - if this is required at all. In a home system, a VM copying and having enough disk space, shouldn't be an issue. (Workstation Pro has Snapshots, but that is not really necessary for this and isn't exactly the same thing).

@funk4food  . "In my case kubuntu 21.10 is the guest, not the host. Can this still be a problem?" No, I did not mean that. I was just saying that with my hardware, 21.04 would not install as a Host ... that is what you have. There may be something, "not so good/robust" in it (but that is speculative, because my Host is rather old but good: Asus Motherboard, i7 2nd gen (I think). So far, my Host has been running smoothly everything in VMware (except Windows 11 Dev versions, very latest ones, as described elsewhere). I'm trying now 21.10 beta (latest) on Kubuntu 20.04 Host (similar hardware). So far so good, live version worked well, but let us see how it goes when I get it installed and updated.

@funk4food . Actually, according to this: https://kb.vmware.com/s/article/80807 the kernel of Kubuntu 21.04 is not supported with VMware Workstation 16.x, not yet. In some other threads have been discussions about patches & other ways to go around the problem. EDIT: Actually, I double-checked and at least initial Kubuntu 21.04 seems to have 5.11.x kernel. The same major version as 20.04. I guess, you already knew this if installation went without problems.  Kubuntu 21.10 Beta seems to have 5.13 kernel - perhaps your problems are caused by that with VMware.