Product Licensing in Scheduled Batch

3571
16
01-04-2013 07:00 AM
AprilNunn
New Contributor
I have an application that selects records from a SQL Server table and geocodes the address, returning the XYs and populating fields in the row. This app was originally written for ArcGIS 9.3, later modified for 10. It was called from either a scheduled task (Server 2008) or xp_cmdshell in SQL Server (2008r2) and worked perfectly.

But after moving to 10.1 the application no longer works from batch. It runs fine in a command window logged into the server as any user, including the account used for tasks/jobs. It stops when attempting to bind the license with the following error in the Event Log. Any ideas?


[INDENT]Faulting application name: geocode.exe, version: 0.0.0.0, time stamp: 0x50e6f6bf
Faulting module name: AfCore_libFNP.dll_unloaded, version: 0.0.0.0, time stamp: 0x4f920360
Exception code: 0xc0000005
Fault offset: 0x5963e9b0
Faulting process id: 0x9230
Faulting application start time: 0x01cdea912fe817ed
Faulting application path: C:\tasks\geocode.exe
Faulting module path: AfCore_libFNP.dll
Report Id: 6e229a8d-5684-11e2-9618-78e7d1ec71be[/INDENT]


Thanks,
April
0 Kudos
16 Replies
T__WayneWhitley
Frequent Contributor
It sounds like your compiled app worked with a module referenced that no longer exists or - I like this kind of error message, "...is no longer supported."  It seems because you upgraded your exe cannot interact with ArcGIS as before...so my suggestion is if it is any way possible, to 'rewrite' the code in Python (or scripting of your choice) or recompile it after you debug it in VS (provided you have source code).

Hope that helps...sorry I have only a suggested 'cure' and not the antidote.
0 Kudos
AprilNunn
New Contributor
I've considered rewriting in Python but i'm not sure that will be the fix. The dll referenced in the error does exist, and does not throw an error when run from command prompt. Only in a batch situation does this error occur. What would make the batch Python any different?

Thanks,
April
0 Kudos
T__WayneWhitley
Frequent Contributor
hmmmm, see what you mean...I'd be interested to know what this line means, why would this dll be a problem?:

Faulting module path: AfCore_libFNP.dll
0 Kudos
T__WayneWhitley
Frequent Contributor
...apparently that's a Flexnet dll?  So you have a system problem, is that concerning the license manager?...did you get that far in troubleshooting, see this for example:

http://systemexplorer.net/file-database/file/afcore_libfnp-dll
0 Kudos
JohanFredriksson
New Contributor
I've considered rewriting in Python but i'm not sure that will be the fix. The dll referenced in the error does exist, and does not throw an error when run from command prompt. Only in a batch situation does this error occur. What would make the batch Python any different?

Thanks,
April


Hi April,

We are having the same problem, but with a windows-service. It runs fine from command-prompt with an exe. But as soon as we put it back in the service we get THE EXACT same message as you.

Did you solve it? (Pleeease say you did...) 🙂
0 Kudos
RichardWatson
Frequent Contributor
Running a program in the context of a service is not, in general, the same as running it from the command line.

One key difference is that services are often run using the System account.  That account is special in that it is very powerful on the local machine but it has no network rights, e.g. you cannot access a UNC share.

Another difference is that services run in Windows session 0 which has many implications.  One implication is that there is no UI.  Attempts to do things like display a message box will, depending the API, either hang the process or generate an exception.

There are other, more subtle differences, as well.

One thing that you can do to help figure this out is to use the SysInternals psexec utility:

http://technet.microsoft.com/en-us/sysinternals/bb897553

You will want to check out the "-i 0" and the -s switches.  If you Google on these keywords then you will find a lot of useful articles.

Another trick is to use the Sysinternals Process Explorer utility to look you process.  What you want to do is to look at the details of the process properties.  It will show all the security information, environment variables, etc. related to the process.  For example, perhaps the PATH environment variable is different.
0 Kudos
JohanFredriksson
New Contributor
Running a program in the context of a service is not, in general, the same as running it from the command line.

One key difference is that services are often run using the System account.  That account is special in that it is very powerful on the local machine but it has no network rights, e.g. you cannot access a UNC share.



Our service in running under user-account with the correct privs. It is the same user we test with command-exe.

EDIT: Nooooo. Apparently it was not the correct privs as when i changed to my admin-account. It worked! Our service-account had been downgraded on the test-machine OR 10.1 demands more of the account running the service and binding the license, then earlier versions. THANKYOU!
0 Kudos
AprilNunn
New Contributor
Hi April,

We are having the same problem, but with a windows-service. It runs fine from command-prompt with an exe. But as soon as we put it back in the service we get THE EXACT same message as you.

Did you solve it? (Pleeease say you did...) 🙂


Yes I did, after determining the problem was permissions on the service account (as related in the other post). But another issue I ran into was our security team - service accounts aren't allowed the necessary privileges here, and I am required to use a security account for scheduled jobs. So I re-wrote my app to use locator and map services instead of accessing the database directly. It might be a smidge slower but speed really isn't an issue in our use.

Glad you got it fixed,

April
0 Kudos
JohanFredriksson
New Contributor
Yes I did, after determining the problem was permissions on the service account (as related in the other post). But another issue I ran into was our security team - service accounts aren't allowed the necessary privileges here, and I am required to use a security account for scheduled jobs. So I re-wrote my app to use locator and map services instead of accessing the database directly. It might be a smidge slower but speed really isn't an issue in our use.

Glad you got it fixed,

April


Hi April,

Would you know the exact privileges the account need?

Thanks
Johan
0 Kudos