Re: How to call Dialog window (formed as resource) from a .DLL
Thanks Igor,
Quote:
The fact that breakpoint appears inactive, and loading dll does not result in breakpoint hit makes me think that you have attached to process other than the one that actually loads your DLL. It's very unlikely that your CAD somehow prevents debugger from normal working.
When I run CAD tool it doesn't load automatically my .DLL. The linking process is executed when in the CAD (already running) I do some particular procedure called "design elaboration" (I won't go into details what it is). Probably (sorry again) during this procedure the initial CAD tool runs some other module and "this other module" links my .DLL. But Ok, I'll try your proposition concerning InitInstance.
Quote:
as the latter blocks thread normal execution while DllMain must never be blocked.
Beside the dubugging issue, should I reject "DoModal approach" in favour of one, based on Create function ?
Regards,
Pavel.
Re: How to call Dialog window (formed as resource) from a .DLL
Quote:
Originally Posted by
Pavel_47
Thanks Igor,
When I run CAD tool it doesn't load automatically my .DLL. The linking process is executed when in the CAD (already running) I do some particular procedure called "design elaboration" (I won't go into details what it is). Probably (sorry again) during this procedure the initial CAD tool runs some other module and "this other module" links my .DLL.
That's the problem -- do you know what module loads what DLL's? Again, please run your application, and use Process Explorer to tell you what module has loaded which DLL's.
http://technet.microsoft.com/en-us/s...rnals/bb896653
From the link above:
Quote:
The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you'll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you'll see the DLLs and memory-mapped files that the process has loaded.
You need a complete understanding of how your program works. Otherwise, you will never be able to debug it.
Regards,
Paul McKenzie
1 Attachment(s)
Re: How to call Dialog window (formed as resource) from a .DLL
Quote:
The fact that breakpoint appears inactive, and loading dll does not result in breakpoint hit makes me think that you have attached to process other than the one that actually loads your DLL. It's very unlikely that your CAD somehow prevents debugger from normal working.
Quote:
That's the problem -- do you know what module loads what DLL's? Again, please run your application, and use Process Explorer to tell you what module has loaded which DLL's.
Igor, Paul you had reason - the process I attached to, is not that, which calls my .DLL. Please see below
Attachment 30879
There is problem - vsim, .DLL is attached to doesn't appear in the list of processes when the CAD is just running. It's called by parent process vish.exe - the one I attached to. Is there some workaround ?
Regards,
Pavel.
2 Attachment(s)
Re: How to call Dialog window (formed as resource) from a .DLL
Re: How to call Dialog window (formed as resource) from a .DLL
Quote:
Originally Posted by
Pavel_47
Here are zooms:
It is impossible to read when the highlight is purple.
Place a DebugBreak in your code, as Igor already mentioned:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
Then when the DebugBreak is called, you are then given the option to debug.
Or do something that delays the application vsimk.exe, so that you have time to attach to it.
Regards,
Paul McKenzie
3 Attachment(s)
Re: How to call Dialog window (formed as resource) from a .DLL
Quote:
It is impossible to read when the highlight is purple.
Here it is:
Attachment 30885
Here is extract of code with DebugBreak:
Attachment 30887
Unfortunately it doesn't catch control, at other side it has impact on .DLL loading. It's failed:
Attachment 30889
Regards,
Pavel.
Re: How to call Dialog window (formed as resource) from a .DLL
Quote:
There is problem - vsim, .DLL is attached to doesn't appear in the list of processes when the CAD is just running. It's called by parent process vish.exe - the one I attached to. Is there some workaround ?
Attaching a debugger at startup
Debugging Process Startup
1 Attachment(s)
Re: How to call Dialog window (formed as resource) from a .DLL
Quote:
Originally Posted by
Igor Vartanov
Thanks. With this approach I could debug. As I've told already my primary aim became Create-based approach. Here is CallStack on the BreakPoint:
Attachment 30891
I stepped 4 function on the stack:
1. InternalDllMain
2. DllMain
3. __DllMainCRTStartup
4. _DllMainCRTStartup
During this stepping I've just controlled dwReason parameter (that was equal to 1 (means DLL_PROCESS_ATTACH, what seeems to be correct)) and also hDllHandle, which wasn't NULL. The retcode from DllMain was 1.
As I've already mentionned in one of my previous mails, the window doesn't appear. To get it diplayed I should "restart" already loaded design. During restart there is also break in the .DLL. Here is VS2010 output window content between 2 breaks:
Code:
vsimk.exe has triggered a breakpoint
'vsimk.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\imagehlp.dll', Cannot find or open a required DBG file.
'vsimk.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\dbghelp.dll', Cannot find or open a required DBG file.
The thread 'Win32 Thread' (0x193c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xa50) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x484) has exited with code 0 (0x0).
Detected memory leaks!
Dumping objects ->
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp(4553) : {299} client block at 0x087FF758, subtype c0, 56 bytes long.
a CObject object at $087FF758, 56 bytes long
d:\proj_modelsim\pli_vpi\pixie3_vpi\pixie3_gui\pixie3_gui.cpp(68) : {289} client block at 0x087FF1E0, subtype c0, 148 bytes long.
a CPixie3_DLG1 object at $087FF1E0, 148 bytes long
Object dump complete.
'vsimk.exe': Unloaded 'D:\PROJ_ModelSim\PLI_VPI\PIXIE3_VPI\Debug\Pixie3_GUI.dll'
'vsimk.exe': Unloaded 'C:\Windows\SysWOW64\mfc100ud.dll'
'vsimk.exe': Unloaded 'C:\Windows\SysWOW64\msimg32.dll'
'vsimk.exe': Unloaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\comctl32.dll'
'vsimk.exe': Unloaded 'C:\Windows\SysWOW64\msvcr100d.dll'
'vsimk.exe': Unloaded 'C:\Windows\SysWOW64\mfc100enu.dll'
'vsimk.exe': Loaded 'D:\PROJ_ModelSim\PLI_VPI\PIXIE3_VPI\Debug\Pixie3_GUI.dll', Symbols loaded.
'vsimk.exe': Loaded 'C:\Windows\SysWOW64\mfc100ud.dll', Symbols loaded.
'vsimk.exe': Loaded 'C:\Windows\SysWOW64\msvcr100d.dll', Symbols loaded.
'vsimk.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\comctl32.dll', Cannot find or open the PDB file
'vsimk.exe': Loaded 'C:\Windows\SysWOW64\msimg32.dll', Cannot find or open the PDB file
'vsimk.exe': Loaded 'C:\Windows\SysWOW64\mfc100enu.dll', Binary was not built with debug information.
vsimk.exe has triggered a breakpoint
As you can see there is memory leak issue. After second break I didn't step through code - merely clicked on Continue. At the end the Dialog Window appeared, but after some short time (about 2...3 min) the CAD window and Debug Window crashed.
Is there some particular parameter inside mentionned functions that should be checked in order to unmask the problem ?
Regards
Pavel.
Re: How to call Dialog window (formed as resource) from a .DLL
Quote:
Originally Posted by
Pavel_47
Is there some particular parameter inside mentionned functions that should be checked in order to unmask the problem ?
First, no one can solve memory leaks without the entire code and running it.
Second, you should be checking the return code of those functions you're calling, instead of assuming that they work. You say the window isn't displayed, so where is your check for the return value of pDlg->Create() and other functions?
Regards,
Paul McKenzie
2 Attachment(s)
Re: How to call Dialog window (formed as resource) from a .DLL
Here they are:
Attachment 30893
Attachment 30895
Regards,
Pavel.
Re: How to call Dialog window (formed as resource) from a .DLL
Quote:
Originally Posted by
Pavel_47
As I've already mentionned in one of my previous mails, the window doesn't appear. To get it diplayed I should "restart" already loaded design.
And as I already mentioned before you should find out the reason why your first launch fails. Your first suspect is pDlg->Create. Please debug it through.
And do us a great favor, please stop sending us your screenshots, and get to real investigation on your side. When you find something suspicious, first try finding relevant info with Google and MSDN. Then try to ask your team. I don't believe that CG is your only source of knowledge. But if it is, please ask questions specific to your current problem(s). When you are asked to provide a code, the code should be a project, concise and compilable. It must not be your full project you are working on. Instead it must be a demo that specifically focuses on your problem. Please take this point very seriously.
I suggested you to launch your DLL in a simple C++ client to eliminate effects from CAD. Well, did you?
Re: How to call Dialog window (formed as resource) from a .DLL
Quote:
Originally Posted by
Pavel_47
Here they are:
As Igor mentioned, how do you know your code even works in a very simple environment? Where is your test stub executable to see if the DLL works? Where is the application that is very simple that loads your DLL and tests it? Where is your version of a "vsimk.exe" application that loads the DLL? It isn't that difficult to write one that just loads your DLL and sees what happens.
Right now, you're trying to figure out all of these extraneous processes, executables, who calls what, etc. That is not the way a programmer develops a DLL. You write a very simple application, whether it is a Win32 that calls LoadLibrary()/GetProcAddress() and calls a couple of the exported functions, or an app generated by MFC wizard and use your DLL, etc. Then you debug that application to see how your DLL works with it. All of this extra CAD stuff is totally not necessary, and only adds to the confusion.
If it does not work in a simple application, then get it to work in a simple application. Once you have it working, then you apply it to the larger, more complex application.
Regards,
Paul McKenzie
3 Attachment(s)
Re: How to call Dialog window (formed as resource) from a .DLL
Hello,
Here (in attachment) is the project where DLL that works properly (in the solution there is also test application).
Here is its diagnostic output:
Code:
InitInstance starts ...
PreCreateWindow starts ...
TestDLL.exe has triggered a breakpoint
PreCreateWindow Last error: 0
PreCreateWindow finishes !
TestDLL.exe has triggered a breakpoint
OnCreate starts ...
'TestDLL.exe': Loaded 'C:\Windows\SysWOW64\shell32.dll', Cannot find or open the PDB file
Warning: Creating a pane with no CDocument.
OnCreate RecalcLayout Last error: 0
OnCreate ShowWindow Last error: 0
OnCreate OnInitialUpdate Last error: 0
OnCreate SetActiveView Last error: 0
OnCreate ResizeParentToFit Last error: 0
OnCreate finishes !
InitInstance LoadFrame Last error: 0
InitInstance ShowWindow Last error: 0
InitInstance finishes ...
Here is test application execution result:
Attachment 31063
When I try the same code (with #define CAD_TOOL in the application class definition) with my CAD tool, the window TODO:layout doesnt appears. Here is DLL diagnostic in the CAD output window:
Attachment 31065
The error 1421 (control ID not found) occurs while executing of the m_pMainView->ShowWindow(SW_SHOW) command inside of Frame class OnCreate function.
Regards,
Pavel.
Re: How to call Dialog window (formed as resource) from a .DLL
Hello,
After a lot of different attempts I'm hampered an obstacle, that apparently without issue.
The application that calls my .DLL is stopped on the following command (with some error message informing that it's just stop working, without any detail):
Code:
CWnd* pNewView = this->CreateView(&ccx);
Here is the whole code of function, where it appears:
Code:
int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
vpi_printf("Inside of OnCreate ...\n");
if (CFrameWnd::OnCreate(lpCreateStruct) == -1)
return -1;
Sleep(20000);
//DebugBreak();
CCreateContext ccx;
ccx.m_pNewViewClass = RUNTIME_CLASS(CMainView);
vpi_printf("RUNTIME_CLASS\tLast error: %d\n", GetLastError());
CWnd* pNewView = this->CreateView(&ccx);
vpi_printf("pNewView\tLast error: %d\n", GetLastError());
m_pMainView = DYNAMIC_DOWNCAST(CMainView, pNewView);
vpi_printf("DYNAMIC_DOWNCAST\tLast error: %d\n", GetLastError());
if(!m_pMainView)
{
vpi_printf("Creation of view failed !!!\n");
}
RecalcLayout();
m_pMainView->ShowWindow(SW_SHOW);
m_pMainView->OnInitialUpdate();
SetActiveView(m_pMainView);
m_pMainView->ResizeParentToFit(FALSE);
return 0;
}
When I uncomment DebugBreak() and during pause of 20sec attach to process I can pass through the suspected code.
But the problem is - in debugging mode evrything is OK !
Does anybody can propose some work around ?
Regards,
Pavel.
Re: How to call Dialog window (formed as resource) from a .DLL
Quote:
Originally Posted by
Pavel_47
When I uncomment DebugBreak() and during pause of 20sec attach to process I can pass through the suspected code.
Those lines did nothing except move the problem somewhere else. Adding in a Sleep() is a sure sign that either you've corrupted memory and the Sleep() just moves the bug to another place, or you have a multithreaded program and your code causes a race condition.
All you're doing when you add and remove lines is to change the executable so that the bug is in another place. I bet if you added a few "int i = 0; ++i", the code would also magically "work".
Quote:
But the problem is - in debugging mode evrything is OK !
You have either
1) Corrupted memory or
2) Caused a race condition to occur or
3) Using uninitialized variables or
4) A combination of 1), 2) or 3).
Quote:
Does anybody can propose some work around ?
You have a function, it doesn't work. The only "workaround" is for you to debug and fix the function. Putting in Sleep() is no fix, as right now, it is no different than adding some local variables and incrementing them.
Regards,
Paul McKenzie