I don’t know if I’m the only one to which this happened, but I’m going to post here the answer.
In the source code of our products we use the RPC API calls CoCreateGUID (followed by UuidToString and RpcStringFree).
Until recently we used them scarcely, and only by calling the ANSI version (UuidToStringA and RpcStringFreeA).
Now due to an increased amount and frequency in communication with the cloud, the GUIDs being a great ally in identifying items across distributed environment, we call both ANSI and UTF16 versions of the API and way more frequently, especially when users uploads data from our devices to their network.
We started seeing frequent situations where the device freezes at the beginning of an upload procedure, happening in almost random points between this part of the code execution, and we eventually found out the application always got stuck in a RpcStringFree call.
I haven’t been able to find any of this explained or mentioned on google, so I can confirm the cause.
We eventually made changes in our code to force it to always use only the ANSI version of these API calls, as it seems the UTF16 are the ones that fail (specifically RpcStringFreeW).
My testing so far seems to prove this. I’ll update this post if something changes.
Just so you know, avoid the UTF16 one and use the ANSi one.
StringFromGUID2 also looked like a good replacement, if needed.
