Nonexpected behavior on WIndows XP SP3

Hi supportrecently I've encountered very unusual behavior of TA on the customer target OS: Windows XP SP3 English

Details of the issues are as follows:

Trial period active, not yet expired, customer has bought a registration code and wants to register the product.After the 1st try to enter the reg code an error was returned from TA core

Following investigation shown that (wow!) reg code was stored in TA system as TA returns it when I'm asking for it (using turboactivate.TurboActivate.GetPKey(); java API)Now, I"m trying to register again using same regcode, but I"m having even more unexpected behavior - TA throws the error "you are running under virtual machine)ie, the APIpublic static void Activate() returns this: case 17: // TA_E_IN_VM throw new VirtualMachineException();

and most interesting issue that (wow!) reg code is seen @ dashboard as non activated!

I'm using default java code, eg:TurboActivate.IsGenuine(90, 14, true, false);it returns me NonGeniune (thats OK until I'm in trial mode, but Not OK after I've tried to use legal reg code)

and TurboActivate.UseTrial(); to be in trial mode (still have 3 days left)

Now, I"m putting here some details in pictures.1) ta file does not allow running under VMhttp://prntscr.com/1qlwje

2) reg code is not seen as being activated in dash boardhttp://prntscr.com/1qlwls

3) unexpected exception thrown on live win xp sp3 OS:http://prntscr.com/1qlwpg

all is fine on other OS (eg win7x64, etc)

Please review the issues and put the recommendations.It is really a high priority as the product and used TA is already in production mode.Thanks

If you want to allow virtual machines, then set the product key to allow activations on virtual machines.

SamVM disabled in ta file and that's just fine according to intention.one out of three questions was: why that exception is thrown on live Windows OS?it's not expected to happen, IMHO

Dear Sam,

To make it more clear we are paid customers and a few clients who are running Windows XP are not able to activate our product. We don't want to allow VMs cause everything is working fine on Win 7/8 (clients have been activated successfully) and we expect to find the way to fix the bug on Win XP.

So we are opened for all the propositions of how could we resolve this issue asap.

I'm not sure what the question is. There are 3 facts:

  1. The customer is running on a virtual machine.
  2. You disallowed the customer to activate the key on a virtual machine.
  3. TurboActivate correctly blocks activation on the virtual machine.

Everything is working as expected. If you want to allow them to activate on a virtual machine, then edit the product key and select that option.

Some misunderstanding here. The customers are running on real Windows XP (not VMs) BUT we are getting some strange errors from TA and one of them shows that we are under VM - BUT of course we are not! I kindly ask you to re-read my first post.

So:

1. The customer IS NOT running on a virtual machine. This case is about the real OS.2. Yes we disallowed the customer to activate the key on a virtual machine.3. TurboActivate DOESN'T correctly blocks activation on the REAL OS. The case is described in my first post and it is detected on Windows XP only (the activation under Windows 7/8 is running OK with the same source code!).

BUT we are getting some strange errors from TA and one of them shows that we are under VM - BUT of course we are not!

Are you running Hypervisor? Do you have it enabled? Even if you're the "host" OS and you have hypervisor enabled, then you're running in a VM. That's just the way the hypervisor is designed.

1. The customer IS NOT running on a virtual machine. This case is about the real OS.

I don't suspect that's true. But shoot me an email (support@wyday.com ) and I'll send you a tool you can use to verify that.

3. TurboActivate DOESN'T correctly blocks activation on the REAL OS. The case is described in my first post and it is detected on Windows XP only (the activation under Windows 7/8 is running OK with the same source code!).

TurboActivate doesn't discriminate between operating systems. It activates fine on everything from Windows XP to Windows 8.1 (including all the Server products).

What you're seeing is TurboActivate detect a machine as a virtual machine. I suspect it's a correct detection, but I'll only know for sure once you shoot me an email and I'll send you a tool.

Email sent - waiting for the tool.

I've sent it.

Responded with the detailed report.

Any updates here?looks like TA has got a false positive reaction on some VM?...... 😠

Alex, we've just responded to your email. Here's a quick summary:

Everything is working correctly. TurboActivate is correct detecting VMs as VMs.

The first case was you running under a hypervisor. Hypervisors are a special type of a VM where even the "host" operating system is techinally on a VM.

The second case was TurboActivate seeing a real computer. I'm not sure why you included this.

The third case was TurboActivate correctly detecting a virtual machine because either the user was running under VirtualBox or they were spoofing their MAC address.

We also got a case where the customer swears that they are running on a physical computer yet are unable to activate. Can't get a straight answer as to which OS is being used though. The particularity was that they installed using a CD-ROM that was shared from another computer. Could that be a cause? I really don't think so since the CD is not required to run the application (and activate) but maybe that info gets stored somewhere.

TA errs on the side of false negative. That is, we'd rather detect a VM as a real computer than detect a real computer as a VM.

That being said, maybe the user is seeing a bug in TA. But I doubt it. In every case where a customer insists they're running on a real computer (and TA says otherwise) it turns out TA is right. Either the customer didn't understand what a VM actually is, or the IT people in the company don't explain these concepts to the "regular users".

Now if you want us to check into this for the customer, then we will. But I suspect this is another case where the customer is running on a VM, but they just don't know it.

(Also, where the customer installs your app from -- CD Rom, etc. -- doesn't matter one way or the other).

I got confirmation from the customer - who is the IT expert for an airport, not just a user - that the computer that can't activate is indeed running XP SP3.

The customer provided the complete system information file, upon my request. From that file do you think you can deduct if the underlying PC is real or virtual? There is a mention of terminal services in there but then again I dumped that same file from a physical test computer and got the same mention.

Unless that customer is really taking us for a ride, there really seems to be an issue under XP SP3.

From that file do you think you can deduct if the underlying PC is real or virtual?

Perhaps. Send it to me anyway at wyatt@wyday.com. If there's not enough information then I'll send you a tool that the customer can run on the computer that will collect more information.

Also, I assume the customer is running a version of your app that integrates the latest version of TurboActivate (currently 3.4.3), correct? We have fixed bugs in previous versions.

No, that application has been out for a while. It uses the TA dll+exe 3.4.1. I'll download 3.4.3 and ask them to try activation with that. I'll let you know. Thanks for the input.

Customer came back with a negative. The new version did not change the behavior and activation stills fails, reporting a virtual environment.

I'll be sending you the system info file. You said you had a tool for debugging also?

TA 3.4.4 is now out and this bug is fixed. You can get it on your API page.

Reply
Discard post