Forum

Hi,

I upgraded from 2.82 to 2.84 and now I get a crash in my application whenever I click on the title bar, if for example I try to move the window.

The crash happens in "extncframe.cpp" line 3003 or 3012, as a result of a call to AfxGetThread() that returns a null handle.

Please let me know how to fix this.

BTW, I think all the users and you yourselves would benefit from a better "forums" application. The current one has very poor performance and the search is virtually unusable - maybe my answer is already in here somewhere, but because I can’t do an advanced search, I get a flood of irrelevant results and then I have no choice but to post my question and waste your time and mine.

Thanks,

Adrian

Please provide more details about the crash. Did you rebuild your project(s) completely after switching to Prof-UIS 2.84? The ::AfxGetThread() API invocations mentioned in your e-mail are performed by the algorithms of the CExtNCW template class, which implements drag-n-drop and resizing of the window with skinned non-client area (caption and borders). If the ::AfxGetThread() API returns NULL pointer, then the global instance of the CWinApp-derived class in not available. Such situation should never occur. But it can occur if you are using some MFC regular DLLs or MFC based ActiveX modules which do incorrect MFC state management.

- I rebuilt all components of the project.
- My project contains a thin exe and a bunch of dlls and all the dll exported functions call     AFX_MANAGE_STATE(AfxGetStaticModuleState());
- the main window is in fact a dialog which runs in its own thread (DoModal is called in a thread procedure) and it’s on this thread that the crash occurs
- the application works fine as long as I don’t click on the title bar,
- the application didn’t have this problem with 2.82.

Here’s the call stack in case it matters:


>    ProfUIS284md-RDE.dll!CExtNcFrameImpl::NcFrameImpl_PreWindowProc(long & lResult=0x00000000, unsigned int message=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 3003 + 0x11    C++
    ProfUIS284md-RDE.dll!CExtNCW<CExtResizableDialog>::WindowProc(unsigned int message=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 604 + 0x27    C++
    mfc71d.dll!AfxCallWndProc(CWnd * pWnd=0x0214bf40, HWND__ * hWnd=0x00391676, unsigned int nMsg=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 241 + 0x1a    C++
    mfc71d.dll!AfxWndProc(HWND__ * hWnd=0x00391676, unsigned int nMsg=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 389    C++
    ydownloaderlibd.dll!AfxWndProcDllStatic(HWND__ * hWnd=0x00391676, unsigned int nMsg=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 53 + 0x15    C++
    user32.dll!7e418734()     
    user32.dll!7e418816()     
    user32.dll!7e42a013()     
    user32.dll!7e42a998()     
    ProfUIS284md-RDE.dll!CExtHookSink::HookChains_t::HookChainsWindowProc(unsigned int nMessage=0x000000a1, unsigned int & wParam=0x00000002, long & lParam=0x01d70510) Line 227 + 0x20    C++
    ProfUIS284md-RDE.dll!CExtHookSink::HookChains_t::g_HookWndProc(HWND__ * hWnd=0x00391676, unsigned int nMessage=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 291 + 0x14    C++
    user32.dll!7e418734()     
    user32.dll!7e418816()     
    user32.dll!7e4189cd()     
    mfc71d.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop=0x00161610, tagMSG * pMsg=0x00000001) Line 3123 + 0x14    C++
    user32.dll!7e4196c7()     
    mfc71d.dll!AfxInternalPumpMessage() Line 188    C++
    mfc71d.dll!AfxPumpMessage() Line 198    C++
    mfc71d.dll!CWnd::RunModalLoop(unsigned long dwFlags=0x00000004) Line 4566 + 0x5    C++
    ProfUIS284md-RDE.dll!CExtResDlg::_DoModalImpl() Line 6370 + 0xc    C++
    ProfUIS284md-RDE.dll!CExtResDlg::DoModal() Line 6314 + 0x10    C++
    ydownloaderlibd.dll!GUIDownloader::run(simlib::ThreadBase::ThreadContext * context=0x00000000) Line 1481 + 0x14    C++
    miscd.dll!simlib::ThreadBase::threadProc(void * p=0x02101ed0) Line 1457 + 0x38    C++
    msvcr71d.dll!_threadstartex(void * ptd=0x020ce7f8) Line 241 + 0xd    C
    kernel32.dll!7c80b713()


Thanks,

Adrian

We still suspect the MFC state is not managed correctly in your project. Please try to insert the following line of code at the beginning of the InitInstance() virtual method of the CWinApp-derived class in your EXE project:

CExt_ProfUIS_ModuleState::InitExtension( ::AfxGetAppModuleState() );

I did this and now I’m getting an assert - see the call stack below:

ProfUIS284md-RDE.dll!CExtResDlg::_DoModalImpl() Line 6337 + 0x19    C++
    ProfUIS284md-RDE.dll!CExtResDlg::DoModal() Line 6314 + 0x10    C++
    ydownloaderlibd.dll!GUIDownloader::run(simlib::ThreadBase::ThreadContext * context=0x00000000) Line 1481 + 0x14    C++
    miscd.dll!simlib::ThreadBase::threadProc(void * p=0x02184ac0) Line 1457 + 0x38    C++
    msvcr71d.dll!_threadstartex(void * ptd=0x020ce810) Line 241 + 0xd    C
    kernel32.dll!7c80b713()     


The assert line is

    ASSERT( hInst != NULL );


thanks,

Adrian

This is another report from you which can be related to the MFC state switching problem. First of all, please ensure the DLL which uses the RDE version of Prof-UIS invokes the CExt_ProfUIS_ModuleState::InitExtension( ::AfxGetStaticModuleState() ); code in its InitInstance() virtual method of the CWinApp derived class. If this is done, then it’s time to do experiments with your main EXE project. You should try creating configurations of your EXE project which do not load particular DLLs and find configuration which does not have reported problems.

Added this line to the dll project but I’m still getting the same assert.

Do you have an explanation why the application ran fine using 2.82 or lower, but not with 2.84? Any change in 2.84 that may cause this?

Adrian

Prof-UIS versions 2.82 and 2.84 are different. Some classes have new message handlers and hooks, some have removed. We have consultations with our customers related to all the possible Prof-UIS library configurations and the MFC state management issues are reported enough rarely. We suspect it’s hardly possible to code a test project which emulates this issue. So, it would be easier to connect to your desktop remotely and debug this issue in your real project.

I reverted everything to the orginal code that worked with 2.82 and set a breakpoint in AfxGetThread. This function gets called many times and it returns the right value every time. Only when I click on the title bar the call fails in the 2.84 dll as shown in the first stack trace above. All these tests and the fact that it worked with 2.82 make me believe that there is a bug in 2.84 that’s causing this call to fail.

Let me know if you need any more info from me to diagnose and fix this bug.

I would appreciate a quick resolution, as I am blocked by this issue.

Thanks,

Adrian

Is it possible to connect to your desktop remotely and debug this issue in your real project?

Yes, I believe we could do that. What software do you use for this, and when would you be available?

You can email me at the address in my account and we can arrange the details.

Thanks,

adrian

We received your e-mail. We can connect to your desktop at any convenient time for you. Please provide us with information about how to do this. You can use a service like www.logmein.com.

This is revised in PROF-UIS 2.85x

However, prof-uis2.84 has degrade.

Is this slightly fatal....  OnGridCellInputComplete does not work....  

Where do I get 2.85? It’s not on the downloads page.

There is Prof2.85x in the Ftp site of Prof.

For details, you please ask support by an email.   support@prof-uis.com 

 

I agree about the forum...