|
From: Adrian G. <gan...@gm...> - 2016-04-06 07:33:45
|
With regards to your suggestion about the %prompt% environment variable,
we tried to do the call from powershell using
[System.Environment]::ExpandEnvironmentVariables("%prompt%"). We added this
in a powershell script and added a scheduled task that runs under local
system account, just as the Adobe Connect Service is configured in
services.msc. Unfortunately, this worked as expected - the name was
expanded to the values that we can see in the registries.
Is there any way to try the above piece of code with a java call, to
simulate what the wrapper does and see if we get any error message?
Kind regards,
Adrian
On Wed, Apr 6, 2016 at 9:24 AM, Adrian Ganea <gan...@gm...>
wrote:
> Hi Alexandre,
>
> Thank you for your feedback!
>
> Device manager was the first place I checked when I saw the error.
> Couldn't find any issues there - moreover, we have 2 web front ends for
> this application and both fail with the same error. As I said previously,
> we have the same error when trying to install on any new machine created in
> the same domain so this is why I believe this is not a hardware related
> problem(device not functioning, etc.) but rather it has something to do
> with OS configuration/change(group policies/a windows update that may cause
> the issue). Does this make any sense?
>
> Event viewer captures only the 7000(the adobe connect service failed to
> start...) and 7009(a timeout was reached(30000) while waiting for the
> Adobe....) errors when trying to start the service. Still, the 7009 error
> is not relevant, that 30 seconds timeout is not reached, the error message
> pops up immediately.
>
> Kind regards,
> Adrian
>
>
>
>
> On Wed, Apr 6, 2016 at 6:15 AM, Alexandre Klein <
> ale...@ta...> wrote:
>
>> Adrian,
>>
>> Thank you for your message.
>>
>> This error happens when the Wrapper tries to load the system environment
>> variable from registry.
>> In your case, it seems that the Wrapper can get the values from the
>> registry but the problem occurs when it tries to expand variables (i.e.
>> when it encounter a variable between '%'). In the log message we can see
>> that it failed when resolving %prompt%.
>> This piece of code is executed only when the Wrapper is running as a
>> service. That's why you don't see this error when running in console mode.
>>
>> As you mentioned, this error happens before loading the JVM.
>>
>> Based on this message "a device attached to the system is not
>> functioning" (which is from the OS), is there any problems with your
>> devices in the Device Manager?
>>
>> Also, do you see any error messages in the Event Viewer?
>>
>> Regards,
>> Alexandre Klein
>>
>> Alexandre Klein
>> Tanuki Software, Ltd.
>> 6-18-10-4F Nishi-Kasai, Edogawa-ku
>> Tokyo 134-0088 Japan
>> Tel: +81-3-3878-3211
>> Fax: +81-3-3878-0313
>> http://www.tanukisoftware.com
>>
>> On Tue, Apr 5, 2016 at 3:01 PM, Adrian Ganea <gan...@gm...>
>> wrote:
>>
>>> Good morning,
>>>
>>> We have an Adobe Connect installation based on Java Service
>>> Wrapper Standard Edition 64bit 3.3.9.
>>> The operating system which the application runs on is Windows Server
>>> 2008R2 Standard Edition.
>>> After trying to install windows updates and restarting the machine, we
>>> noticed that the Adobe Connect Service(ConnectProService) couldn't be
>>> started using services.msc - it immediately threw the error message "The
>>> service did not respond to the start or control request in a timely
>>> fashion".
>>> The only error that is thrown in *wrapper.log* is "wrapper | Error |
>>> Unable to expand prompt - a device attached to the system is not
>>> functioning". The problem is that we reverted(using a VM snapshot
>>> from a day ago) the updates and we still have the issues. We also tried to
>>> do the installation on other machines on the same domain and we have the
>>> same issue, so I'm assuming that this can be caused by a GPO(we tried on an
>>> isolated test domain and it's working) issue.
>>> We even ran procmon.exe(sysinternals) and it indicated the same issue - "Invalid
>>> device request".
>>> For the moment we have a workaround - start ConnectProService in console
>>> mode(using -c switch) and all looks good with the application. Since the
>>> application is functioning properly using this switch, we believe there is
>>> a problem with the java service wrapper. Moreover, starting the
>>> application as a service doesn't even get to load the JVM, so playing with
>>> the *wrapper.conf* file didn't help too much(setting
>>> wrapper.debug=true, etc.).
>>> Have you encountered this issue before? Any other ideas on what to try
>>> next?
>>>
>>> Kind regards,
>>> Adrian Ganea
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Wrapper-user mailing list
>>> Wra...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>
|