RXOP

Dear RIDP Team,

We are writing to request your urgent assistance with a stability issue our customer (World Food Programme) is experiencing with the Kofax ControlSuite PCC application on the Ricoh MP C307 model.

1. Application Description

Our application, the PCC client, is a multi-threaded android application running on the SOP panel. During its startup process, it initializes a significant number of internal services. Many of these services need to read their initial configuration from the device's internal storage (HDD) to function correctly.

2. The Problem: Application Intermittently Hangs on MP C307

We have confirmed through multiple log sources that our application frequently hangs during its startup phase or takes a very long time to respond, but this issue only occurs on the MP C307 model. The same application package runs normally on newer models like the IM C3000 within the same customer environment.

This application hang causes the device's internal watchdog service to forcibly terminate and restart our application, leading to a lengthy and often faulty recovery process that requires the user to reboot the device.

This issue has been present from the very beginning. The customer has tested multiple versions of our PCC application (including our most stable releases and the latest version), and the problem persists across all of them.

3. Suspected Cause: Platform/Hardware-Related

Our initial investigation of the device logs revealed numerous exceptions related to the card reader module. We asked the customer to remove the card reader for further testing, but the application remained extremely sluggish.

After a deeper analysis of the device logs, we have provisionally identified the cause of the hang to be within our persistence module, which handles read/write operations to the device's storage. We have concrete evidence from the device's own system logs that suggests the platform's behavior is a key factor contributing to this instability.

Evidence A: Direct Proof of Deadlock and "waiting to lock" State

A system-generated ANR (Application Not Responding) trace file shows a classic deadlock scenario.

• Log File: traces_1753892592474.txt
• Key Log Entry:
• Crucial Observation: We have searched our entire log database across all Ricoh models we have ever handled. This waiting to lock state within our persistence module has only ever been observed in the device logs of the MP C307 model. We believe this strongly points to a model-specific issue.

codeCode

"main" ... waiting to lock <0x42e310d8> (a java.lang.Object) held by thread 101 "neuf_ebs-34"

Evidence B: Watchdog Intervention

The watchdog service log confirms that it terminated our process for being unresponsive.

• Log File: watching/20250930_164426_0151
• Key Log Entry:

codeCode

[2025/09/30 16:44:26(JST)][23034] [WARNING] Process is not responding.

[2025/09/30 16:44:26(JST)][23034] [WARNING] Kill process.

Evidence C: Signs of a Stressed System

The device logs also show that the platform was under heavy load even before our application hung.

• Log File: PCC Decoded Log (containing system messages)
• Key Log Entries:
  • System UI Freeze: 09-30 16:39:17.023 ... Choreographer: Skipped 33 frames! ...
  • Memory Pressure: 09-30 16:46:50.706 ... dalvik-vm: WAIT_FOR_CONCURRENT_GC blocked 468ms

4. Our Hypothesis and Request for Confirmation

Our primary hypothesis is that the I/O performance (HDD access) on the MP C307 during its busy startup phase is significantly slower or less stable compared to newer models. This unusual latency causes threads in our application to hold locks for an abnormally long time, dramatically increasing the probability of the deadlock we are observing.

Given that this issue is specific to the MP C307 model and is triggered by I/O-intensive operations, could you please help us confirm if this is indeed a known hardware limitation or a platform compatibility issue?

We are attaching the complete device log package (MachineInfo_C518PA01348...) for your analysis, along with a video clip from the customer that demonstrates the system's sluggishness.

Thank you

Hi RiDP support,

After maintenance. I cannot find this ticket https://ricoh-ridp.com/ridp/support-system/incident/kofax-usa/1758164874/21109624/5627

The above ticket is not updated.

Please advise.

Thanks.

Due to be unable to use logcat temporarily, can this (attached) tar file be decrypted? 

There is a customer that is having a reboot issue during our installation, and normally, we'd decrypted the logs before opening an incident.  We will be collecting additional rxist rxop debug logs in the coming days before asking for more specific guidance.

Hi RiDP support,

We got some errors when using RXOP to check WIM and serverlet on device.

10/09/2025 11:33:58 AM The exception when call https://10.212.110.235:51443/dsdk/StartServlet, org.apache.http.conn.HttpHostConnectException: Connect to 10.212.110.235:51443 [/10.212.110.235] failed: Connection refused: connect

9/10/2025 11:34:39 AM Error when Polling HTTPS WIM authentication screen for device 10.212.110.235 failed: No connection could be made because the target machine actively refused it 127.0.0.1:3128

We attached Machine Log.

Please advise.

Thanks.

Hi RiDP support,

We got this error when using RXOP to install application to the device:

install -- STATE_INSTALL_ERROR ERR_SOP_VERSION_UPDATE_PROHIBITED :: Device version up lock mode. :: :: ::

Model: Ricoh IM 2510

We are waiting for machine log and rxop logs.

Please advise.

Thanks.

Hello,

I have received some emails from Wolfgang Razen and Yuhei Sasaki who are attempting to deploy our Authentication, Secure Print and Secure Scan applications for Ericsson.

They are getting a failure when attempting to do the deployment:

06 Aug. 2025 09:28:21 MRDP6004E EXCEPTION OCCURRED DURING RICOH DEPLOYMENT PROCESSING - -- init -- COMMON_NOT_AUTHENTICATED
06 Aug. 2025 09:28:21 MRDP6005E STACK TRACE
MRDP6005E ricoh.rxop.rxcommon.RxopException: -- init -- COMMON_NOT_AUTHENTICATED

I have attached the deployment log, the rxinst log and the device tracelog. I didn't really see anything in these logs that indicate what the issue is. When we have typically seen this error in the past, it means the username/password are incorrect. Wolfgang has assured me they are correct here.

Here is some information from Wolfgang on the type of user they are using to do the deployment. Wolfgang says if they use a default device admin, the deployment works just fine.

The device has 3 types of admins running.
1) The default device admin using the old mechanics. That admin account is the one which was used before Flexible admin Role was introduced. That admin user works fine with VPSX embedded installation.
2) A LDAP group which is keyed to the 4 usual admin functionalities (Device, Network, User, File). When using a user from that LDAP group the device will grant that user the admin rights on the device. I have not tested yet if that user can install VPSX embedded.
3) Another LDAP group which is keyed to a template with privileges (and I have given all privileges available). A user from that LDAAP group will be granted those privileges when the user logs in. In the Web Image Monitor (WIM) it is shown that this is an admin with custom privileges assigned. That user fails to install VPSX embedded with he results I have provided you yesterday.

It is this 3rd admin that is failing to be able to deploy our solutions. 2 questions I had for them are can this 3rd user login to the device using the ROC and do those types of admins have authority to do installation and configuration using RXOP. Neither Wolfgang nor Yuhei knew the answers to these. I don't think they have access to the ROC either.

So, my question is, how do I determine if this is something caused by our deployment code, something with the device configuration, a bug, or simply something that isn't supposed to work this way?

Regards
Bryan

Hi RiDP support,

Could you please tell us whether RXOP can work with java versions:

Java 8 x64

Java 11 x86 and x64

Java 17 x86 and x64

Java 21 x86 and x64

Java 24 x86 and x64

Java 25 x86 and x64

Thanks.

Hello Team,

We've used the Remote Operation Client (ROC) v1.6.5 from the rxop-downloads page to install / uninstall application on the Ricoh SOP devices in our office.

https://ricoh-ridp.com/resources/downloads/roc-rxop-v165

We have a couple of questions
1. Are we allowed to redistribute the ROC client as-is ? ( to our clients )
2. If yes, is there a specific packaging requirement around how it should be done?

Greetings, our mutual customer Biogen reported an issue with our Ricoh Remote Card Reader Management (RRCRM) Application; as a reminder RRCRM is used to install our RfIdeasReaderPlugin.

RRCRM includes a call to RicohJavaDevice.isUseVMlessApi to see if an installation of rxConfServlet is required. If required, RRCRM will use rxop to install rxConfServlet.

We recently updated RRCRM to use rxop version 3.8.9, and we're seeing failures installing rxConfServlet on IM C4500. Some investigation showed that rxop version 3.8.9 has a reference to 3.5.3 of rxconfServlet, which is a significant downgrade from the 3.8.8 version that rxop 3.8.8 used. I see the Ricoh download page has ServletComponentsFor3.8.9 available with the description that starts, "Repackaged servlet components for v3.8.9 with correct signatures"

Should we be taking the ServletComponentsFor3.8.9 and replacing the rxconf servlet that ships with rxop 3.8.9? Any additional guidance you could provide around this area would be helpful.

Hi RiDP support,

Our customer check rxsp servlet  from an IM 370 device and got this error:

[rxinst-10.12.110.44-1549565508][2025-07-16 15:46:16] INFO  - ---- DmServletResponse ----
[rxinst-10.12.110.44-1549565508][2025-07-16 15:46:16] INFO  - url: https://10.12.110.44:443/DH/devicemanagement
[rxinst-10.12.110.44-1549565508][2025-07-16 15:46:16] INFO  - status: 404
[rxinst-10.12.110.44-1549565508][2025-07-16 15:46:16] INFO  - rawData: <html><head><title>404 Not Found</title></head><body><h1>404 Not Found</h1></body></html>

Tried lots of changes to MFD certificates etc but it fails

Tried with Admin no password as well as current device password. Also changed certificates, disabled and enabled TLS 1.3.

Device was factory reset this morning and a template applied from a working machine but it just wont work.

Other devices of different models work ok but this single IM 370 will not work

We attached rxinst log, machine log

IP device is  10.12.110.44

Please advice