Upgrade to 2017.08.0: TRA strings work fine but number values return 0

[jmoleary]

I'm having a problem using TRA with FlexNet embedded in my C++ application. At startup, after loading the TRA environment, I can successfully retrieve all the string values from TRA aliases but any attempt to retrieve a *number* from a TRA alias returns a value of 0. The tra_get_value() function does not report any error, it just sets the output parameter to zero. It doesn't matter whether I try to go through the TDT type or if I make a raw call to tra_get_value().

This is for a TRA file and project that has worked perfectly until now.

I'm using FlexNet Embedded 2017.08.0.
I have just upgraded from version 2016.08.0.
Even once I upgraded, I used the same identity header files that I generated back in version 2016.08.0. I'm running with a license file that I generated under that identity as well.

Any idea what I'm doing wrong here or how to determine what the problem is? Am I supposed to generate new identity files every time I upgrade the FlexNet embedded SDK version? I hope not. Otherwise I would have to issue new licenses to all my clients just to give them a new binary.

Edit: I've recently discovered that this only happens if I am debugging the application. If I run the application outside of the debugger, everything works fine. Again, I don't understand this as until now, I was able to debug just fine. My TRA file debugging options are set to allow debugging and they have not changed: Here is the relevant section



options.debug = {
["trace"] = false,
["allow_debugger"] = true,
["allow_failure"] = false,
["visual_studio"] = true,
}
options.header = "MyCompanyName"
options.TDT = { ["typename"] = "TFT" }
options.verify_modules = {
[ "windows" ] = {
["kernel32"] = { ["checksigned"] = true },
["User32"] = { ["checksigned"] = true },
["wintrust"] = { ["checksigned"] = true },
["crypt32"] = { ["checksigned"] = true },
["psapi"] = { ["checksigned"] = true, ["lazy"] = true },
["FlxCore"] = { ["checksum"] = true, ["lazy"] = true, ["target"] = "FlxCore64" },
},
}

options.multithreaded = true

[jmoleary]

Managed to solve my own problem. Doesn't look like too anybody answers things here so maybe this will help the next guy.

Apparently the options settings I had still allow you to debug on Visual Studio 15 but never allow you to debug on Visual Studio 17

options.debug = {
["trace"] = false,
["allow_debugger"] = true,
["allow_failure"] = false,
["visual_studio"] = true,
}


That "allow_failure" needs to be set to true if you want the TFT integer variables to work when debugging. But the worst part is that in the sort of failure I was having they simply fail silently. They just return 0. I would have hoped for an exception or something.

[mjolnir]

This is the sort of behaviour (integers returning zero) you would see if tampering is detected. It was a design decision not to raise exceptions in the event of tampering as it could yield clues to someone attempting static analysis of the code.

To diagnose your particular issue you should enable TRA trace which will hopefully give you an explanation of what is failing. I would speculate that the reason why tampering appears to be detected in your scenario is that there is a software breakpoint set in the protected executable/dll, which effectively modifies the code section (even though it appears not to have). TRA correctly identifies these changes as tampering. Clearing all breakpoints would hopefully solve the problem (albeit making debugging more challenging!).

Some debuggers use a different approach to debugging involving hardware breakpoints and you might have more success there (see http://www.nynaeve.net/?p=80 for an overview of the differences).

Hope that helps!

[mjolnir]

We share your frustration. We have observed almost exactly the same experience ourselves and our best speculation is that Visual Studio debugger is adding its own breakpoints for whatever purpose but doesn't necessarily make them visible to us (the end user), as they are entitled to do.

You could try capturing the trace as I mentioned before, and raising a support ticket and attaching that, but it's possible we won't have much luck tracking it down I am sorry to say. If you do raise a ticket be sure to mention full Visual Studio version (ideally the version output of cl.exe), architecture and so on.

For development purposes it may be easier to set ["allow_failure"] = true just whilst you are working on it, but don't forget to set it back before release.

Hope that helps!