Hi,
I have a c11 app that freezes for several seconds. During this “freeze” there is a flood of WM_APP + 12316 messages.
Not sure if my code is the source of these messages or not. I’ve searched for 12316, B01c, 301c, 45084 w/o any luck.
Anyone have a suggestion on how to narrow down the source of the messages?
Hi @JaredDavis,
did you find the source of the messages? We have a similiar problem with message 45084 right now.
Best regards
Philipp
Hi,
Sorry. Never found the source.
Hi,
Not sure if this will help you.
https://docs.microsoft.com/en-us/previous-versions/ms915533(v%3Dmsdn.10)
Regards
Johan de Klerk
Do you create controls on the fly?
Hi Everyone,
it seems, that ClaRun calls PostMessageA from WinApi and floods the queue with these messages.
I noticed that on a single click on the application menu, the window procedure receives this message (45084 / 0xB01C / WM_APP+12316) about 60 times!
The problem in our case becomes critical when the environment is more heavily loaded - increased database or network load, the application performs a more time-consuming operation, etc. Then, it not only leads to short application freezes, but to a complete crash of the application due to the message queue overflow (ERROR_NOT_ENOUGH_QUOTA) and when it occurs, 99% of messages are of the above mentioned type. It looks like the runtime floods itself - it generates more message than it can handle afterwards.
Does anyone know for what purpose or under what circumstances this message is generated? What should we check?
Regards,
Andrzej
Yes, we do. In many cases we dynamically create toolbar buttons and add menus. We also have windows that are fully populated with dynamically created controls, but they are usually not too big and we have not noticed any problems with them.
But shortly after switching from C9 to C11 we had to give up the dynamic menu for our largest window because the application crashed when closing the window.
Currently our other biggest problem, besides message queue overflow, are deadlocks appearing in different moments - usually during the termination of a thread out of scope of our code. Windows event log shows “Cross-thread Deadlock” in these cases. I don’t know if these problems could be related somehow, but if an application loses its ability to post/receive messages, anything can happen.
Regards,
Andrzej
I would try adding a call to
debugerNameMessage (*CSTRING, UNSIGNED EventNum ),RAW,NAME(‘WslDebug$NameMessage’)
Note in a WndProc you can just call this undocumented RTL command to get descriptions of WM_Msg
some of which are SV specific names.
FWIW you can use the same undocumented RTL command to convert EVENT() to a string like “EVENT:NewSelection”, by adding A0000H to the eventNum (or adding 1400H for CW 55 and older)
Edit: I check the value of WM_APP + 12316 - it just returns 0xb01c so no help there.
Thanks Mark! Interesting, even if not very helpful in this case. 
Best regards,
Andrzej
Hi,
Our program uses a lot of create on the fly controls driven by a java backend running drools. I was unable to reproduce it in a small program.
We are migrating to a different front end now. Please let us know if you find the source or a solution.
Regards,
Jared
There’s been a post on the sv.clarion.clarion11 newsgroup from Siegismund Günter where he describes an issue they’re having integrating .NET with Clarion…
Why do we get ERROR_NOT_ENOUGH_QUOTA?
This error means that thread message queue is full.
I checked what kind messages are inside the message queue when it’s full.
99% of messages were of type 45084 (int), 0xB01C (hex) with wParam=0, lParam=0
Who generates the message 0xB01C?
It’s Clarion runtime.
Verified in x32dbg debugger by setting conditional breakpoint on User32.PostMessageA.
Their solution was to remove those message from the queue…
…apply a simple workaround: remove all messages of type 0xB01C before showing the window or before creating WPF controls.
Full details are in a Word file attached to the newsgroup posting.
Could it be possible that there’s a subclassing procedure somewhere that might not be returning properly? e.g., somehow the RETURN XXX gets bypassed, leading to an undefined return result?
Siegismund has replied on the Clarion11 newsgroup and apparently SkAn is part of the team 
Well I’ve done some digging using Rohan’s API Monitor trapping PostMessageA and the call stack shows it’s being called by
WslDebug$SetLogFile
It’s the same both for msg 45084 and 45057, and both messages repeat over and over.
Looking at the source in IDA Pro Free I can see it’s the bit of the RTL that keeps track of the call stack and then puts stuff in the crash dump file C110Log.TXT when there’s a crash.
(at least that’s my interpretation of the info from IDA Pro - I’m not a x86 assembler guy )
Makes sense that CLARUN has to keep a running queue of stack calls so that if a crash occurs it can dump the information out to C110Log.TXT
If the code is compiled in non debug mode are the messages still generated? Is it as simple as turning off debug mode?
IIRC WslDebug$SetLogFile is used to the FileName “C110Log.TXT”
in other words, it should only need to be called once
Decades ago, I tapped into that system to generate text files, without adding the Text file driver
there are some related undocumented RTL commands that the write to the file…
(probably a bad idea… but, that’s a different conversation)
WslDebug$Print
WslDebug$PrintEvent
WslDebug$PrintHex
WslDebug$PrintLine
etc.
FWIW here are ALL of the WslDebug$ procedures in the RTL (as of C11.0.13505)
No those repeated messages still appear in Release mode 
Yes you’d think it should only need to be called once.
You have made so much progress. Thanks for sharing the information.
Have you contacted support? Can they provide any insight into those methods? Request some way to disable that code for the next rtl build? Call it a speed improvement?