|
jkirkerx wrote: Access violation reading location 0x2102fe2b
What this is telling you is that you're trying to access memory that has either been deallocated already or it is stack memory that belongs to another thread. What variable is in that address? Where and how was it allocated? That should lead you to the cause of your problem.
|
|
|
|
|
I need a quick lesson on that. If I can find out what is there, I can fix my errors faster and be on my way.
|
|
|
|
|
Whenever the error comes up, you can break execution then go to the call stack and trace your path backwards to see where (within your code, not the framework) the error occurred. If you have a memory address such as this, you can look at the variables involved in the call that gave you the error and see which one has that address, that will tell you which one caused it (although it's still up to you to figure out why the error occurred).
|
|
|
|
|
I've traced my issues down to the parameters that I'm passing to the thread. I must of implemented it wrong, and left it in memory. I thought it clears automatically when the thread exits.
So this is on the CreateThread Side of the Function, and of course I read the parameters back on the Thread side.
Question:
do I have to clean up here manually, or is it automatic?
PMAIN_RUNPROCESS pzUpdateProcess;
pzUpdateProcess = ( PMAIN_RUNPROCESS ) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof( PMAIN_RUNPROCESS ));
pzUpdateProcess->m_hWndDlg = _updates_Dialog_hWnd;
pzUpdateProcess->m_StatusMessage = lbl_Update_Dialog_StatusMessage_Label;
pzUpdateProcess->m_ProgressBar = pb_Update_Dialog_ProgressBar_Field;
hThread = (HANDLE)CreateThread(
&sa,
0,
&_updates_Dialog_CreateProcess_Thread,
pzUpdateProcess,
0,
&dwThreadID
);
The Code Analyst is complaining about a DPAC (ACL) or something below. Is it really needed for proper operation?
SECURITY_ATTRIBUTES sa;
sa.bInheritHandle = TRUE;
sa.lpSecurityDescriptor = NULL;
sa.lpSecurityDescriptor = (PSECURITY_DESCRIPTOR) malloc(SECURITY_DESCRIPTOR_MIN_LENGTH);
InitializeSecurityDescriptor(sa.lpSecurityDescriptor, SECURITY_DESCRIPTOR_REVISION);
SetSecurityDescriptorDacl(sa.lpSecurityDescriptor, TRUE, (PACL) ->NULL<-, FALSE);</b>
sa.nLength = sizeof(sa);
sa.bInheritHandle = TRUE;
sa.nLength=sizeof(SECURITY_ATTRIBUTES);
|
|
|
|
|
I didn't size it correctly, and found I had to use HeapFree to clean the memory after the thread returns.
Wow, now it works, and strange behavior went away.
PMAIN_RUNPROCESS pzValidate;
pzValidate = ( PMAIN_RUNPROCESS ) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof( MAIN_RUNPROCESS ));
HeapFree( GetProcessHeap(), 0, pzValidate );
pzValidate = NULL;
|
|
|
|
|
By default, anything you manually create on the heap, you must manually free. Thread will only deallocate its own stack memory.
|
|
|
|
|
I'm learning Albert. It just never dawned on me that's what the holdup was on all the other problems I had with the dialog boxes, and sql server connections.
Now I can go back and use the advice and suggestions given to me over the last week.
Thanks for listening, I appreciate it.
|
|
|
|
|
Happy to help when I can... 
|
|
|
|
|
First time on this forum. Hello
I wish my first post was shorter.
And forgive the obscure title. It's hard to nail it short - I don't even know what the actual problem is.
Here's a quick description of what happens:
1) My_exe launches a 3rd_party_exe via CreateProcess(). The main process thread is in a suspended state.
2) I WriteProcessMemory() in the 3rd_party_exe process, and copy in it an absolute path, pointing to a dll I wrote.
3) I CreateRemoteThread() to have the dll loaded. It's the trite and dull LoadLibraryA() method everybody knows.
This secondary thread is created not suspended.
4) I do stuff... My_exe opens a named and synchronous pipe. My dll inside 3rd_party_exe will connect to it. My_exe writes down the pipe a path pointing to a text file. My dll inside 3rd_party_exe retrieves such path, then closes the pipe. Control is back to My_exe, which disconnects the pipe and closes the handle. No errors. Never an error.
5) My_exe now WaitForSingleObject() that the (remote) thread from point 3 gracefully comes to an end. And it always does. When that thread is done, my DllMain() has returned. I do not unload my dll from the 3rd_party_exe process. I need it to stay loaded.
6) Time to cleanup. With the remote thread closed, the memory I wrote in the process is no longer needed. So I call VirtualfreeEx() to deallocate it.
7) Only now I let the main process thread run (remember? it was kept 'suspended' since CreateProcess()).
8) I do not need to wait for 3rd_party_exe to terminate. My_exe can close. I CloseHandle() the main thread handle and the process handle (from CreateProcess()), in that order.
9) End.
What I described works -- *almost* always.
I check for errors after every API call.
When there's a problem it's VirtualFreeEx() (from point 6) reporting Access Violation (0xc0000005).
The puzzling thing is that WriteProcessMemory() is always successful. You see, I wouldn't advance all the way to VirtualFreeEx() otherwise 
Any idea what might be causing this?
I can repeat this procedure on a number of 3rd_party_exe programs. None crashes, except the one that does (lol, sorry).
I thought that perhaps this crashy program is doing something special as it starts... something that prevents me from accessing my own memory (the one from WriteProcessMemory())... but then I thought that it can't be, as the error occurs _before_ I even resume the main process thread.
How would it be interfering??
Help.
|
|
|
|
|
According to #5, you are doing all of this piping and text file retrieving inside the DllMain function?
That's a recipe for errors right there. You are never supposed to do anything but the most rudimentary initialization inside DllMain.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Thanks.
I'm unaware of specific limitations to observe or -in general- 'good conducts' to keep while inside DllMain().
I'll trust your input, and seek documentation about it later. As for the immediate...
... since the main process' thread is kept suspended and I alone decide when to let it run...
... would it be safe to CreateThread() from inside DllMain() and move all my code in there?
Or is CreateThread() another bad practice when in the context of DllMain()?
If you know better alternatives I'll listen.
Thank you again for the help.
|
|
|
|
|
|
*reading*
Hmm. Looks like that, to program today, one has to have the knack of the lawyer as well. Can't do this, Don't do that, But this is okay if, Unless, Just watch for, ...
Jokes aside, now.
It would appear that pretty much anything coming not from kernel32 is not to be invoked from anywhere/anystage_of DllMain().
And even so, some kernel functions directly/indirectly cause the loading of more libraries... which is another taboo.
Fine.
I'm developing for WinXP 32bit. That's the oldest platform I target.
In my case my best option is to resort to the APC mechanism. For example the SetWaitableTimer() (exported by kernel32.dll) can be safely called from DllMain(), and *it* can invoke an APC function on completion (completion which can occur 1) immediately, and 2) autonomously - no need for external inputs).
It's perfect.
Once inside the APC function -> I can do anything I want.
I should be on the right track this time 
But I'll try this out tomorrow. Must sleep now.
Thank you very much for the informative links  (vote: 4)
Feel free to add anything else you think might help.
A good night to you.
|
|
|
|
|
I'm glad you found it useful. Good luck with your implementation.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Dear All,
I am practicing about creating login Dialog as below:
void Login::OnBnClickedOk()
{
if (m_username == "test" && m_password == "test123"")
{
AfxMessageBox("You login successfully!");
UpdateData(true);
CWnd*pWnd;
pWnd = GetDlgItem(IDC_USER);
pWnd->SetFocus();
return;
}
AfxMessageBox("You login incorrectly!");
UpdateData(false);
}
Please help me write "BOOL Login::OnInitDialog()" function!( because I want to call this login dialog)
Thanks!
|
|
|
|
|
Huh ?
Well, your Login dialog should/could be called in the OnInitDialog of the "other" dialog (which I assume is the one that needs to have permission), the one that will call the Login dialog.
If you have the "other" dialog :
// use the OnInitDialog that will be automatically generated.
BOOL COtherDialog::OnInitDialog()
{
BOOL result = CDialog::OnInitDialog();
Login loginDialog;
if ( loginDialog.DoModal() == IDOK )
{
}
else
{
}
return result;
}
Watched code never compiles.
|
|
|
|
|
|
In this context, calling UpdateData() is not serving any useful purpose.
Le Quang Long wrote: Please help me write "BOOL Login::OnInitDialog()" function!
It should have been done for you automatically. If not, right-click the Login class and select Properties. In the Properties window, click the Overrides button. Do you see OnInitDialog in the list?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
|
Hi Experts,
How can I restrict copy and paste (from mouse and keyboard) from a view?
|
|
|
|
|
1. Capture the Key Down/Mouse click event
2. Find if it's a Copy(Ctrl+C) action
3. return from the Key down handler if it's a Ctrl+C
It would be good if you can elaborate on what is in that view
You talk about Being HUMAN. I have it in my name
AnsHUMAN
|
|
|
|
|
The question is: what view? Is it MFC Cedit or CrichEdit derived view?
Anyway, you do not have capture anything. Where is the word capture coming from? Windows sends messages that you choose to handle or not you do not have to set any traps to capture.
Anyway, if this is MFC application it has menu items and possibly corresponding accelerator keys combination with the same ID.
For example: ID_EDIT_PASTE has Ctrl-V or CTRL-Insert key combinations.
If you want to completely disable copying pasting, insert do nothing (empty) handlers for those IDs, leave accelerators intact and remove appropriate menu items.
If you want to disable editing under certain condition, use Update UI for those commands.
JohnCz
|
|
|
|
|
By the artical:
http://msdn.microsoft.com/en-us/library/9yb4317s(v=vs.80).aspx[^]
After create a new platform of x64, I can create a new solution configuration for Debug Win64 and copy settings from Debug Win32. But I wonder how to set the properties for the x64 solution. After I create new solution configuration and copy settting from Win32, I found the macro WIN32 is still there, but not replaced by WIN64.
For win64 application, which macro(s) should I set in the /D setting? Should I keep the /DWIN32?
Btw, I found the _WIN32,_WIN64 macro in MFC source code, but not WIN32,WIN64. Which one is required in the /D setting?
Thanks for your inputs.
/Sam
|
|
|
|
|
I think you have't fully understood that article.
When you are copying win32 settings to x64, that article clearly mentioned to change win32 switch to win64 for /D switch
Quote: Values of WIN32 are replaced by WIN64 for /D (Preprocessor Definitions).
Quote: I found the _WIN32,_WIN64 macro in MFC source code
Which source code? your code or in any of the standard headers?
If it is yours, then you should take care to propely to map these settings to win32 and win64 pre-processor definitions
|
|
|
|
|
Some marcos like WIN32/_WIN32 and WIN64/_WIN64 are used by VC++. I am not sure what's the difference between WIN32/WIN64 and _WIN32/_WIN64.
Lakamraju Raghuram wrote: I think you have't fully understood that article.
When you are copying win32 settings to x64, that article clearly mentioned to change win32 switch to win64 for /D switch
Refering to the artical, the WIN32 macro should be repalced by WIN64 with /D switch support. But after I did it under the steps, the WIN32 macro still there but not replaced by WIN64. You may try it from your side. So I am confused by the result.I wonder if it is a defect of vs2008 IDE. Some other articals mentioned that the WIN32 macro always should be set with /D switch and with WIN64 macro definied for x64 application perspectively.
Lakamraju Raghuram wrote: Which source code? your code or in any of the standard headers?
If it is yours, then you should take care to propely to map these settings to win32 and win64 pre-processor definitions
I found the _WIN64 macro in MFC header file of basestd.h. Here a code snap:
#if defined(_WIN64)
typedef __int64 INT_PTR, *PINT_PTR;
typedef unsigned __int64 UINT_PTR, *PUINT_PTR;
typedef __int64 LONG_PTR, *PLONG_PTR;
typedef unsigned __int64 ULONG_PTR, *PULONG_PTR;
#define __int3264 __int64
#else
typedef _W64 int INT_PTR, *PINT_PTR;
typedef _W64 unsigned int UINT_PTR, *PUINT_PTR;
typedef _W64 long LONG_PTR, *PLONG_PTR;
typedef _W64 unsigned long ULONG_PTR, *PULONG_PTR;
#define __int3264 __int32
#endif
So I am not sure which macro I should set in the preprocessor definition setting. By default, VS2008 IDE set the WIN32 macro with /D switch. Also I found _WIN32 macro is used in the MFC header files and source files.
modified 30-Apr-12 7:27am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
