Intermittent EXCEPTION Page Fault during startup – mvLoader / mvRpcTxtFmt threads

Ask Questions B&R Software & Runtime
, ,
1

Hi everyone,

I’m seeing an intermittent issue where the controller enters Service Mode (AR error 25314 – EXCEPTION Page fault) during startup, but only under certain conditions — for example when the Automation Studio logger window is open during boot, or when one or more mappView clients connect very early in the startup phase.

After a restart where the logger is closed and the system is allowed to boot normally, everything runs stable and the error does not reappear.

From the system log, the fault consistently appears in mappView‑related threads, typically named:

  • mvRpcTxtFmtXXXXXXXX
    and the backtrace usually points into:
  • mvLoader (sendStringReturnValue, handleTxtFmtFormat_p, handleTxtFmtFormatThread),
    with the top of the chain involving internal memcpy / bcopy calls before the page fault occurs.

My IEC application does not appear anywhere in the backtrace, and the crash seems to happen entirely inside the mappView/loader threads during early initialization or early HMI‑client activity.

  • Has anyone else experienced similar EXCEPTION page faults in mvLoader / mvRpcTxtFmt during startup?
  • Are there any known issues in Automation Studio 6 / Automation Runtime 6.x related to mappView initialization or early client connections?
    In our case, we did not see this behavior before migrating the project to AS6.
  • Any recommended workarounds or best practices (e.g. delaying HMI client connections, known patches, configuration adjustments, etc.)?
    We are using AR 6.5.1 and mapp View 6.5.0.

Any insights or experiences would be greatly appreciated!
Thanks in advance.

2

I’m not sure if this is directly related, but after reviewing various discussions and recommendations, one plausible cause could be text/string handling in the mappView stack during startup—specifically the internal text formatting and memory copying in mvLoader / mvRpcTxtFmt when many texts must be loaded or rendered at once (e.g., alarm texts, labels, snippets).

If that’s the case, it would align with the idea that page faults can occur at unexpected or edge conditions in internal memory copies, and with occasional reports of rare exceptions linked to mappView processes.

If this type of behavior is indeed the root cause, are there any recommended guidelines for how much text to expose to mappView—for example maximum lengths or best‑practice ranges for:

  • alarm texts
  • snippets / formatted strings
  • tooltips

Also, are there any configuration settings or best practices to reduce the amount of text data pushed during the startup phase (or to delay certain text initializations), thereby lowering the risk of these exceptions in the mappView threads?

3

Hi @Rickard_Odgren ,
Which hw do you have?
Could you upload SystemDump?
Sincerely I see wrong memory access, that can be related to your code (memcpy/memmove/strcpy/…) or system task/library. If the issue is related to system task/library you should see usually same pattern in the logger.
Any helpful information on the backtrace?

Have you already analyzed the issue with the profiler?
Do you have the same issue if you downgrade AR to 6.0, mapp View to 6.0, OPC UA c/s to 6.0? That combination in my experience is very stable…hehe.
Which language do you use for your code? ST/c/ladder? If the language is not c you can add Iec Check library, or maybe you already did that. This library implements checking functions for division, modulo operators, range violations, array accessing, as well as read/write operations performed on memory locations.

Reference:
Troubleshooting page faults
How to create a long profiler with enough data for analysis
Thanks
Ciao
Valerio

4

Hi @Valerio,

Thanks for your reply!

I am using the following CPU: 5APC3100_KBU1_000.

I’ve mainly analyzed the issue using the Logger / System logbook. The pattern is very clear: the faults occur inside mappView‑related threads, usually tasks named mvRpcTxtFmtXXXXXXXX, sometimes also mvRpcServer. The call chain is always the same: bcopy/memcpy → send/arsend → mvLoader (sendStringReturnValue / handleTxtFmtFormat_p / handleTxtFmtFormatThread). I never see my IEC task anywhere in the backtrace, which makes me think the exception happens inside system/library threads rather than in my own code.

The controller most often enters Service Mode during startup, showing 6804 memory access violation followed by 25314 EXCEPTION Page fault (from the SystemDump logbook). This happens especially when multiple mappView clients are connected, but it has also occurred with just one client, or when a new client connects early in the startup phase.

The application is written in ST, and I’ve tested with IEC Check — nothing relevant is reported, which aligns with the fact that the crashes appear inside mappView/system tasks rather than IEC user code.

Systemdump_260216.txt (618.9 KB)

The SystemDump shows repeated EXCEPTION Page faults (25314) on
2026‑02‑12 (11:28:29, 12:14:03, 12:28:46) and
2026‑02‑16 (07:43:31, 09:00:38),
all linked to ArException and associated with mvRpcTxtFmt / mvRpcServer. Matching memory access violations (6804) appear at the exact same timestamps. Around these events there are also RPC call timeouts and mvRpcWatchdog initializations, which fits with a heavy burst of RPC/text formatting activity during startup.

I haven’t yet downgraded to AR/mappView 6.0, and I haven’t run a long profiler session during a failing startup, but I can do so if needed.

The SystemDump I provided includes all exception events, all RPC‑related warnings, version details (AR 6.5.1, mapp View 6.5.0 / mvLoader 6.5.0), and the full logbook history for both 2026‑02‑12 and 2026‑02‑16.

Thanks a lot for the guidance!
/Rickard

5

Hi @Rickard_Odgren ,
thanks for your feedback but unfortunately I can’t open your SystemDump (have you renamed the extension?). You already reported your issue 4 days ago and I don’t see feedback from the Community for similar issue so it’s possible that is related to your project. I don’t see the Community is the best channel to identify the cause of your problem, local Support will help you in better way.Please update us when you have fixed the issue.
I hope to be more helpful next time.
Ciao
Valerio

6

Hi,

My mistake — I couldn’t upload the system dump as an .xml file, so I saved it as a .txt instead.

I will contact the local support team.

Thank you for your advice.

Best regards,
Rickard

7

Hi @Rickard_Odgren ,

normally when I upload the System Dump I save that with default extension .tar.gz as you see below

image
image1801×1032 30.1 KB

image
image2191×1465 119 KB

Thanks
Ciao
Valerio