# IotMqtt reconnect crash (memory access violation in writeUTF) **URL:** \ **Category:** B&R Software & Runtime\ **Tags:** automation-runtime\ **Created:** [April 29, 2026, 3:38pm UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091 "2026-04-29T15:38:32Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Ayman6855](https://avatars.discourse-cdn.com/v4/letter/a/FF8800/32.png) [@Ayman6855](https://community.br-automation.com/u/Ayman6855)\ **Post date:** [April 29, 2026, 3:38pm UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/1 "2026-04-29T15:38:32Z")
Hello, I am using IotMqtt in a cyclic function block. I added logic: - If TCP connection is lost → Enable = false - After a timer → Enable = true (reconnect) This works, but if the connection drops multiple times quickly (connect/disconnect/connect), the CPU crashes with a memory access violation. The crash happens inside IotMqtt (internal functions, e.g. writeUTF). I already check pointers: `if (inst->pMqttClient == NULL) return;` I call IotMqttClient() cyclically. Question: Is it safe to toggle Enable like this on connection loss? Can fast reconnect cycles cause internal MQTT memory issues? ---
**Author:** ![valerio.manenti](https://dub1.discourse-cdn.com/brcommunity/user_avatar/community.br-automation.com/valerio.manenti/32/11712_2.png) [@valerio.manenti](https://community.br-automation.com/u/valerio.manenti)\ **Post date:** [April 29, 2026, 3:45pm UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/2 "2026-04-29T15:45:00Z")
Hi @Ayman6855 , Welcome to the Community! I don’t think we have a standard library for IotMqtt so theoretically we don’t support user library, but we can help you on troubleshooting. Basic questions: 1. Which AS are you using? 2. Which runtime version? 3. We need more information about that library, maybe someone in the Community already used that 4. Could you upload SystemDump? 5. Have you already checked the other posts we have for similar topic: ---
**Author:** ![Ayman6855](https://avatars.discourse-cdn.com/v4/letter/a/FF8800/32.png) [@Ayman6855](https://community.br-automation.com/u/Ayman6855)\ **Post date:** [April 30, 2026, 10:52am UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/3 "2026-04-30T10:52:43Z")
> [@valerio.manenti](#): > > Welcome to the Community! > I don’t think we have a standard library for IotMqtt so theoretically we don’t support user library, but we can help you on troubleshooting. > Basic questions: > > 1. Which AS are you using? > 2. Which runtime version? > 3. We need more information about that library, maybe someone in the Community already used that > 4. Could you upload SystemDump? > 5. Have you already checked the other posts we have for similar topic: Hi Hello, thank you for your response. I am using: - Automation Studio 4.12 - Runtime 4.93 This is not a standard library, it was developed externally. I will upload: - SystemDump - IotMqttLog.txt The issue occurs during reconnect when the connection drops multiple times quickly. The CPU crashes with a memory access violation inside IotMqtt (e.g. writeUTF). I have already checked similar posts, but could not find a clear solution. Any suggestions where to look further would be very helpful. ![grafik](https://europe1.discourse-cdn.com/brcommunity/original/2X/e/efc9f8e2af2bf864b2a929d5d0596eefbd6b312e.png) [Systemdump.txt](https://community.br-automation.com/uploads/short-url/vq69KZR84dkjWR5wjyGHsLT6P8X.txt) (396.9 KB) [IotMqttLog.txt](https://community.br-automation.com/uploads/short-url/ukZtYWURms2oblAK1HLDJi1lcpN.txt) (3.3 MB) ---
**Author:** ![job.franken](https://avatars.discourse-cdn.com/v4/letter/j/FF8800/32.png) [@job.franken](https://community.br-automation.com/u/job.franken)\ **Post date:** [April 30, 2026, 1:50pm UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/4 "2026-04-30T13:50:18Z")
From the systemdump and logging you are using the [GitHub - br-automation-community/paho.mqtt.c-ar: MQTT Client for Automation Runtime based on eclipse/paho.mqtt.c · GitHub](https://github.com/br-automation-community/paho.mqtt.c-ar) The MQTT implementation has an own retry and reconnecting build in. So you should not enable/disable the FUB all the time. In the configuration structure you should find the “AutomaticReconnect” which is default on TRUE. When on FALSE you could also self use the “Connect” input on the Fub. ---
**Author:** ![valerio.manenti](https://dub1.discourse-cdn.com/brcommunity/user_avatar/community.br-automation.com/valerio.manenti/32/11712_2.png) [@valerio.manenti](https://community.br-automation.com/u/valerio.manenti)\ **Post date:** [May 2, 2026, 7:13pm UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/5 "2026-05-02T19:13:17Z")
Any update @Ayman6855 ? Thanks Ciao Valerio ---
**Author:** ![Ayman6855](https://avatars.discourse-cdn.com/v4/letter/a/FF8800/32.png) [@Ayman6855](https://community.br-automation.com/u/Ayman6855)\ **Post date:** [May 4, 2026, 12:38pm UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/6 "2026-05-04T12:38:42Z")
@job.franken thank you for your explanation. I have now set `AutomaticReconnect = FALSE`, but the problem still remains. When the Ethernet cable is unplugged, it takes a long time until the client detects the disconnect. During this time, the client may still report _Connected = TRUE_, but no data is exchanged anymore. Because of that, my function block monitors the MQTT activity (publish/subscribe). If no data is received or sent for a certain time, I trigger a manual reconnect. I also noticed that using only `Connect = FALSE/TRUE` is often too slow or stays in the _disconnecting_ state for a long time. A fast and stable reconnect currently only works if I fully restart the FUB using `Enable = FALSE → TRUE`, especially when the Ethernet cable is unplugged and plugged in again quickly or multiple times. My goal is to achieve a fast and reliable reconnect after physical link interruptions (Ethernet cable unplug/plug), without causing crashes or inconsistent states. ---
**Author:** ![job.franken](https://avatars.discourse-cdn.com/v4/letter/j/FF8800/32.png) [@job.franken](https://community.br-automation.com/u/job.franken)\ **Post date:** [May 4, 2026, 2:36pm UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/7 "2026-05-04T14:36:39Z")
I did some digging. WriteUTF is used in the basic part of the MQTT lib in the MQTTPacket\_send\_subscribe function and other send locations. `/**` `Writes a “UTF” string to an output buffer. Converts C string to length-delimited.` `@param pptr pointer to the output buffer - incremented by the number of bytes used & returned` `@param string the C string to write` `/` `void writeUTF(char* pptr, const char* string)` The MQTT is starting a thread to handle all things my guess is that a quick disable/enable already deletes the memory of the thread while its actively is being used. (While some code exists in the fub to counter that . but guess its not 100% proof) What times did you configure for the maxRetryInterval and ConnectTimeout etc ? You still could put data in the que while the connection is not working or recovered. The data is then send in one go ones it is restored. ---
**Author:** ![Ayman6855](https://avatars.discourse-cdn.com/v4/letter/a/FF8800/32.png) [@Ayman6855](https://community.br-automation.com/u/Ayman6855)\ **Post date:** [May 4, 2026, 3:03pm UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/8 "2026-05-04T15:03:27Z")
The three timers (MaxRetryInterval, MinRetryInterval, ConnectTimeout) are currently set to 0. Could this be the reason for the issue? The problem happens randomly, especially when the Ethernet cable is unplugged and plugged in multiple times in a row. ---
**Author:** ![job.franken](https://avatars.discourse-cdn.com/v4/letter/j/FF8800/32.png) [@job.franken](https://community.br-automation.com/u/job.franken)\ **Post date:** [May 6, 2026, 9:32am UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/9 "2026-05-06T09:32:12Z")
I would suggest to enter realistic (few seconds ? ) values and check if the automatic recovery then works. ---
**Author:** ![kovarj](https://dub1.discourse-cdn.com/brcommunity/user_avatar/community.br-automation.com/kovarj/32/537_2.png) [@kovarj](https://community.br-automation.com/u/kovarj)\ **Post date:** [May 25, 2026, 6:07am UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/10 "2026-05-25T06:07:30Z")
Hi @Ayman6855 have you found solution for your issue? ---
**Author:** ![Ayman6855](https://avatars.discourse-cdn.com/v4/letter/a/FF8800/32.png) [@Ayman6855](https://community.br-automation.com/u/Ayman6855)\ **Post date:** [May 26, 2026, 11:01am UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/11 "2026-05-26T11:01:27Z")
By reducing the MinRetryInterval, MaxRetryInterval, ConnectTimeout and KeepAliveInterval values, physical connection losses are detected faster, and the issue was resolved by using KeepAlive monitoring and AutomaticReconnect instead of manually controlling Connect. ---
**Author:** ![kovarj](https://dub1.discourse-cdn.com/brcommunity/user_avatar/community.br-automation.com/kovarj/32/537_2.png) [@kovarj](https://community.br-automation.com/u/kovarj)\ **Post date:** [May 27, 2026, 7:22am UTC](https://community.br-automation.com/t/iotmqtt-reconnect-crash-memory-access-violation-in-writeutf/11091/12 "2026-05-27T07:22:41Z")
thanks for update 🙂