This is a weird one. Many of our K&K sales laptop users are reporting running in "Demonstration mode".

I've tried to debug and see if there was a settings issue. Looking at the first report I could, LICENS reported the "license to: [Unlicensed]". The miame.ini reported the correct coname.dat setting, and coname.dat was correct (last modified in 2009). I closed the Windows A-Shell instance, and on launching a new instance it acquired the license.

I did look at the ashlog.log and didn't see any messages referring to Demonstration or coname.dat.

Any ideas, on how to determine what is happening? Is there a trace we put in the miame.ini to log when this event occurs?

TIA

P.S. Window's A-Shell version 6.5.1721.3

Am I correct in assuming that these laptops are running ATE? If so, then the license comes from the server, delivered by an automatic invocation of the LICENS/ATESRV command which involves some back and forth communication between the server and the client. If the connection is marginal, sometimes that operation breaks down or times out, after which the session may continue to run but will be in demonstration mode.

In that case, you can typically execute LICENS/ATESRV manually to re-init the license (although obviously that won't be practical for end users, especially if the session connection goes straight into a GUI program.)

If you have TRACE=INOUT set on the server, the ashlog.log may have some clues since the first couple of entries include information gathered from the client. (It may not say "demonstration" but the first few timestamps and/or information reported from the client machine may be helpful.) If you also have TRACE=EXEC, then you'll even see the LICENS/ATESRV command executed.

If the problem becomes annoying enough, the sledgehammer workaround is to install individual ATE licenses on the affected client machines.

No these are using Window's A-Shell and TRACE=INOUT already. The end-users have no involvement in the licensing/configuration.

Any more thoughts?

Sorry, I misunderstood the situation. In the case of a locally installed license, it would seem pretty straightforward -- either it's valid or it isn't. Yet you're getting intermittent results? Hmmm...

The only part of the framework that seems open to intermittency would be iffy network response. Are these laptops working completely off of their own local drives? Or do they access either the miame.ini or the coname.dat off of a network drive?

It might help if you could email me a copy of the miame.ini file to play with here.

These are entirely standalone instances of Window's A-Shell installed to C:\vm\miame. They've had the same setup since 2009, actually it's the same Windows A-Shell environment I shared with you a few months ago.

Here's the shortcut command line.

C:\vm\miame\bin\ASHW32.exe -i C:\vm\miame\miame.ini -uo ashvm -o "%APPDATA%\A-Shell\salesman_ashell.ash"

I'm not sure how to explain why it has been working all along, but I think there was a bug in the license key generator back in 2019 (when this license was generated) that didn't have any real world effect until recently (either related to the date or some other internal random combination of environmental bits).

There was a later key generated (in 2021, labeled "testing") that I just tried and it works fine. But as the key is near to its expiration anyway, I'll have Ty generate a new one and email it to you.

Sorry for the trouble!

Awesome. Thanks.

I updated the license for this Windows A-Shell install on 7/26/23 and thought that resolved the issue; however, this still occurs at a high rate. It has not been reported to me until now.

Window's A-Shell version is still 6.5.1721.3

Is there a way to trace the licensing process to help track this down?

ashlog shows every login event. Should be easy to track how many users are logged in at a time. With that being said in my experience once a license is "tagged" in demo mode it doesnt matter if they are the only remaining user on the system it will stay that way until restarting.

Is this the license for s/n 4690 that ends in -YTEZUC5 ?

I've set up an instance here for it and and launched it several times without issue. In my case, the %MIAME% directory is on the local C drive, so there's no networking complication with reading the license from the miame.ini. But is that the case for you? If the -i <miame.ini> spec is on a mapped network drive that these laptops are connecting to over some kind of WiFi network, then my first guess would be that there is some problem reading the license, or the coname.dat file, leading to the demo mode condition. Especially since it sounds like it happens intermittently.

If you think you can get it to happen within a few tries, then you could add the -trace command line switch to the launch, which will generate a slew of trace messages which might reveal some clue, if nothing else, from a time delay in between them. But it's not a practical way to run (since it is so verbose).

The serial number is correct, but Ty's DDS license Google sheet shows the license ending in -43UGR46; which, is the value all of the laptops have for the key.

Do we still not have the correct license key?

These are standalone laptops with A-Shell installed in C:\vm\miame.

I can't easily reproduce this on my own. That's why I was hoping there is a way to trace just the licensing portion, seems like using the trace switch for a regular end user will slow A-Shell down.

I'm not sure why I didn't have that key in my license archive, but it does appear to have been generated a day later than mine and with a year longer expiration. I just switched my test system to use the one you're using, and it also seems to work fine. So no good clues yet. I tried changing one of the digits to force it to fail, and the log ends up looking like this:

Is that basically what you see when it fails? And these are intermixed among a bunch of successful launches?

I looked at the ashlog from a reporting user this morning, and there are no "demonstration mode" messages. They had multiple instances of A-Shell in demo mode this morning.

miame.ini contains TRACE=INOUT

Any plan of action on this?

Steve,

How many users is this system? (out of curosity).
Have you tried getting all users off and erasing jobtbl.sys to reset the ashell environment?
FYI - each user is only allowed i think 2 or 3 instances of ashell at a time. (best of my knowledge). Perhaps some users are burning thru more licenses?

Good luck.

We have a customer with a fleet of laptops for use by their salesforce. They run independent instances of Windows A-Shell on each laptop that require no internet connection while using the main function of these laptops.

Sometimes it happens when they launch the first instance, sometimes the second. They might have one in demo mode, and one not.

Stephen--Sorry for the confusion and problems with this issue. I can't figure out quite what is going on. I'm traveling yesterday and today, don't quite have all my tools and resources as available as usual. Something weird has happened, that's for sure. Again, sorry for the problems. I'll be home this evening and will jump into the problem with both feet, hope to have a resolution in your email first thing Friday morning.

Ty, Hope your travels went well, Thank you!

[sorry - I thought I had posted this yesterday but apparently forgot to click the 'Post' button]

You may have me stumped here. The "Launch error" log messages do not appear to be dependent on any settings and I haven't figured out a way to launch in demo mode without getting one of those messages. Presumably you are getting the first "A-Shell 6.5.1721.7 launched" messages (which are triggered by the TRACE=INOUT)? If not, that might suggest some complete disconnect between the launch command line and the miame.ini (like a bad -i argument).
(It would probably be helpful to see an excerpt of an actual ashlog file; maybe some other clues there.)

Although I don't have any particular reason to suspect this mechanism to be broken in that version, given the lack of any clear paths forward, it might be worth at least trying this with the current 7.0 version to see if there is any change in behavior.

And although it seems unlikely that you're running out of node licenses, we should probably rule that out by running SYSTAT and/or ABOUT to see if somehow you've accumulated a bunch of abandoned-but-not-terminated jobs.

Stephen & Jack: I've read through the sequence above, and checked MicroSabio's license-generation records, and looked at the licenses we've sent to Stephen, and looked at old email messages. I could be missing something, but from what I can tell we DO NOT have a licensing problem. The license that Stephen is using, ending in 43UGR46, is (a) the one I sent him on 7/26 of last year, and (b) the exact same one I get when I re-generated the license key today.

I therefore speculate that the OLD key ending in YTEZUC5 was also good. We replaced it with the new key 43UGR46, and we all assumed that the problem was solved. But Stephen's current report says no, the problem wasn't solved, and the new key is behaving just like the old one did. We just didn't know about it until now.

So I think the "demo mode" message is NOT a license issue, but rather a something-else issue. I don't know what else, but am pretty sure it's not related to licensing. It's possible that there is something wrong with the license logic in A-Shell, but that seems quite unlikely. I'd say that you should assume the license is good and the problem lies elsewhere.

Hope that's helpful....

So all these are single 1 user independent licenses running in single user mode on a laptop? Its also quite possible the users are not ending previous sessions properly and thus old instances of ashell can be seen running in task manager that may not be visible on the desktop. Does rebooting said laptop resolve the problem?

I have a request made to allow me access the next time this is reported.

I've attached a screenshot and ashlog of this incident. The screenshot shows licensed to: [unlicensed], but the coname.dat was correct. The ashlog doesn't contain any details as to why that is failing. We then exited A-shell and deleted the jobtbl.sys and qflock.sys file, and the next launch the licensing worked.

No idea where to go from here.

The only things I see in the ashlog that are at all unusual are:

1) The previous session (the one that presumably shows the Unlicensed message above, appears to have started on March 27? Is it possible they were putting up with the demo mode nag messages for 6 days before exiting the session or launching a new one? Or does the problem maybe surface after the laptop has gone to sleep and wakes up again while the session is still going?

2) Another detail possibly interesting about that session is that there were apparently 2 others opened at that time on that laptop. The indicators for this are that there were 3 nodes in use, but only one license; and the sm=2 in the following line indicates two other sessions from the same machine...

3) A third detail about that same session is that there was no indication of a proper exit for the prior session (i.e. no "Out:" message). Of course that could have been deliberate, but given that the last activity in the log prior to the March 27 launch was on March 22, I'm guessing that the laptop just went to sleep and the user forgot about that prior session, or it somehow got killed off unceremoniously.

I'm not suggesting that there is anything wrong with leaving sessions open but asleep when the laptop goes to sleep. What's still not clear to me is whether the Demo Mode problem surfaces when launching a session (which would be the normal case), or it surfaces later, perhaps after it had been asleep for awhile. In the latter case though, I'm not sure how the user would even notice unless using ABOUT. (On a side note, it is possible that if for some reason the coname.dat file was not readable when you executed ABOUT, it would show "[Unlicensed]" as in your image above, but I don't think it would actually nag you about being in demo mode, since that is established at the time of the launch.)

The only other detail I can think of that might help would be a copy of the miame.ini file.

Here's the miame, I had to add .txt extension for it to upload via the attachment manager.

Waiting to hear back if this is only occurring on new A-Shell instances, or if it happens when resuming an instance from sleep.

I do know the user was complaining that he had to dismiss the demo mode message repeatedly yesterday.

I don't see anything unusual or suspicious in the INI. The one change I would recommend would be to add BASERR,SIGHUP to your TRACE= line. It won't have any effect on the demo mode mystery, but might help document events of interest. (SIGHUP probably has little effect on standalone Windows, but doesn't hurt either, and standardizing what I call the "3 essential traces" -- INOUT,BASERR,SIGHUP -- across platforms makes things easier.)

I guess we'll wait for more info. Note that the only scenario I know of for demo mode is that it gets flagged at the start of a session, forcing you to decline the offer to re-enter the license and click on a message box or two. (It would also record a message in the ashlog, which we aren't seeing.) So the evidence, sketchy as it may be, seem to point to it falling into demo mode sometime later. But in that case, we'll need to figure out what the trigger is. Ideally we'd have a log message for each demo nag, but that would require an update (which wouldn't be a bad idea of general principles but I gather it's not convenient here.)

We're planning on upgrading to 7.0 at some point, but we've had issues in development that have been reported, and don't feel comfortable yet pushing it to production customers. I can update one laptop independently if there's a need to capture newly added logging.

I was hoping maybe to get a bit more information to help tailor any further traces, if needed. But if the problem only happens intermittently, multiple days apart, then maybe I should just go ahead and add a few traces now, hopefully getting us to the resolution sooner.

I talked to the end user, and he claims that "demo mode" starts after A-Shell has been launched and he is using one of our applications. It is usually after closing his laptop lid and resuming at some point later. This didn't seem possible, as you stated "demo mode" and license only occurs on the process startup. He also said this happens once every 3-4 weeks, so not going to be easy to resolve over that timeframe.

I did verify the user is ok with updating Windows A-Shell to add new traces.

Ok, let me ponder that. Is it possible that your app launches additional A-Shell sessions via HOSTEX? I wonder if that could somehow square the circle here (also explaining the multiple instances).

No, we don't have any instances of launching an A-Shell ourselves.

The multiple instances were probably him running a second instance to run a different application.

Hmmm... I might have to do some research into what kinds related to waking up a sleeping machine could somehow be connected....

Ok then -- I suggest using the Help > Check For Updates option to update to 7.0.1757.2. Assuming that you have TRACE=INOUT set, it will now add a trace for each time the demonstration mode message box appears, and also traces for suspend, resume, lid closed and lid opened. It's not clear that's going to solve the mystery, but hopefully it will get us closer.

I'm seeing the following when trying to install from Check for Updates. I had to type from the Windows dialog message, so may not be 100% accurate.

Source file not found:
www.microsabio.net/dist/70rel/bin-win/web/1752.3/ash-7.O.1752.3-web.00003.
Verify that the file exists and that you can access it.

I'm not sure what to make of this. There is no 1752.3 (should be 1757.2), so maybe that was a typo, in which case the issue must have been a momentary network/download problem interfering with the download of that one file. I just did a complete new install from the Help > Check For Updates link (to make sure that all the files are accessible) and it worked. So maybe it's just a matter of trying again. Or, perhaps the real problem is that there's some confusion with the control file opr:ashupdweb.cfg; you can rule that out by just erasing that file (forcing it to be re-downloaded).

I manually downloaded 7.0.1757.2 and will update the end user's laptop.

I just figured out a vector into demo mode.

These salesmen's laptops don't have access to a MySQL database, it's not licensed there either. They run the same programs as K&K's production server; which, does use a MySQL database. A couple of programs attempt to connect to a database, and you receive an ASQL not licensed message, and then I received the "Demo mode" message after.

It doesn't seem like trying to access an unlicensed feature, should remove the current license.



The serial number and A-Shell key where correct.

Good detective work! I'll have to review the logic behind switching to demo mode in this case.

I think the issue was that in order to be practical for the user, the demo mode message is limited to every 15 minutes or so. And in order to be practical for the code, the logic is consolidated into the startup for each program. So it's a convenient simplification to just switch into demo mode when accessing unlicensed features. (The thinking was that it would be developers experimenting with such features, and that they would simply close and relaunch the session in order to turn off the nag messages after the experimentation was complete.)

Otherwise we'd have to maintain a separate timer and separate test on access to each unlicensed feature. And even then it's not entirely clear what makes sense for the end user in a case like this, since they have little or no idea about the code or the licensing.

I would say the message about accessing an unlicensed feature to the end user is warranted, but is disconcerting to switch to demo mode for the end-user.