While launching a MFC application(.exe) as OLE server, some time CWinApp::OnFileNew() gets failed; due to this frame window cannot be created and handle to the main window (m_pMainWnd) becomes NULL and error message "Error occurs in mfc42.dll" appeared.
At windows XP, CWinApp::OnFileNew() failed in 1 out of 100 times.
We have not implemented the OnFileNew() in our application; we are using default implementation of OnFileNew().
As per MSDN CWinApp::OnFileNew implements this command differently depending on the number of document templates in the application. If there is only one CDocTemplate, CWinApp::OnFileNew will create a new document of that type, as well as the proper frame and view class.
Problem occurs only at one system and frequency is one out of 100 and error message "Error occurs in mfc42.dll" appeared.
From your information it is rather impossible to guess what is wrong. But I will give you some notes that may help you to find the problem or enhance your question:
"Error occurs in mfc42.dll" seems to be an application specific error message (googling the exact term gives only a few results). So you should be able to locate the executed source sections before the error occurs.
Even when using the default implementation of OnFileNew(), virtual functions of your document class are involved. In this case I would especially check OnNewDocument(). When this returns FALSE, creation of the document and frame window will be stopped (see the MFC sources for CSingleDocTemplate::OpenDocumentFile()).
I ran into a small problem using Visual Studio 2012 Update 1.
Any MFC dialog that has controls with icons or bitmaps does not show the graphics if it is the first one in z-order. The following controls are displayed correctly.
A simple way to demonstrate this bogus behavior is to generate a dialog application with a couple of MFC EditBrowse Controls (but you could use MFC Buttons with icons as well). You can arbitratily change the z-order of the controls with the result that the icon does not display for the first one (preview is ok but not the compiled application).
I don't know whether this problem occurs in other versions of VS or if I have overlooked something important like proper initialization.
A simple way to get around this problem is to add a control with a picture at z-order 1 and make it invisible such that subsequent controls are not affected.
Your question is pretty valgue as there are a lot of RTOS's out there. A guess, is to put the function in its own thread and make the thread a higher priority than all others so it would not be preempted. Prioritization can be a tricky business though.
HOW the RTOS you are using schedules threads is very important. Many (most?) RTOSs can't actually guarantee a function's run time; they simply run fast enough that with proper programming you can get close enough. Something that takes over 10ms will almost always fall into this latter category since writing a function to use such an exact amount of time is essentially impossible (hardware interrupts alone on embedded system will add enough variance to cause a measurable difference in timings.)