C / C++ / MFC

30-Apr-12 16:54

Well I figured out how to test my compiled output, and find most of the errors.

This is the heart of most of my program failures, and strange behavior. It has something to do with Threads.

On one example, I have a dialog box, that loads parameters. I then click OK, and run the validator, first creating a thread, and the validator runs in the thread, which produces strange errors, like not connecting to sql server.

If I dump the thread, and just run the code function, it works fine, no problem. So I have to decide whether to dump the threads, or try to fix them.

I've tried WaitForSingleObject, and now the MsgWaitForMultipleObjects. On the latter, it just crashes on check return code, in which I run a MessageBox, and crashes.

I am posting this to see if perhaps it just needs improvement. It crashes on Case 1:, but I'm not sure if it really has a problem there or not. The message is Access violation reading location 0x2102fe2b. I don't have the expertise to proceed with the message.

DWORD dwRet;
do {
dwRet = ::MsgWaitForMultipleObjects( 1, &hThread, FALSE, INFINITE, QS_ALLEVENTS );

if (dwRet != WAIT_OBJECT_0)
			{
     MSG msg;
     while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
     {
		TranslateMessage(&msg);
		DispatchMessage(&msg);
     }
}
} while ((dwRet != WAIT_OBJECT_0) && (dwRet != WAIT_FAILED));

DWORD dwExitCode = 0;		
if ( GetExitCodeThread( hThread, &dwExitCode ) ) {
		
	CloseHandle( hThread );
			
	switch ( dwExitCode ) {
		case 0:
		// Create Project Validate was Successful
		bReturn = TRUE;
		break;

		case -1:
		{
		SetFocus( ddl_ProjectCreate_DatabaseName_Field );
		SendMessage( ddl_ProjectCreate_DatabaseName_Field, CB_SETCURSEL, (WPARAM) 0, (LPARAM) 0 ); 
		}
		break;

		case 1:
		// Project type selection error
		MessageBox( g_hWndMainFrame, TEXT("You must select a project type to create\0"), TEXT("Create Project\0"), MB_OK );
		SetFocus( lv_ProjectCreate_ProjectType );
		break;

Code-o-mat1-May-12 0:29

Code-o-mat

1-May-12 0:29

What does your secondary thread do? Show some code if possible. On a sidenote, you mentioned setting strange errors from the thread like not connecting to sql, do you use COM for this? You might need to initialize COM with CoInitializeEx[^] in every thread that does some COM operations (i remember running into this once), did you do this?

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<

jkirkerx1-May-12 6:57

1-May-12 6:57

I wrote a post last week about my program working fine when running in debug F5, but the compiled version has many errors. So I've been running the compiled debug version, and using the just in time feature to locate errors. I fixed most of the errors, but the thread eludes me.

I'm using ODBC to connect to the sql server.

The dialog box runs 1 thread to validate when you press OK, and then the next thread to create the project, in which it copies files to the folder, sets permissions, creates a database and tables, users, permissions, write to the registry, and then opens the project.

The strange behavior on the SQL, is that the first sql function runs correctly, and then the 2nd one won't connect.

This is the sql function

BOOL bResult = FALSE;
	
SQLHENV henv;
SQLHDBC hdbc;
SQLHSTMT hstmt;
SQLRETURN retcode;

SQLWCHAR OutConnStr[1024];
SQLSMALLINT OutConnStrLen;

HWND desktopHandle = GetDesktopWindow();   // desktop's window handle

SQLWCHAR	szDatabaseExist[80];
SQLLEN		cbDatabaseExist = 0;
	
// Allocate environment handle
retcode = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv);

// Set the ODBC version environment attribute
if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {
	retcode = SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER*)SQL_OV_ODBC3, 0); 

	// Allocate connection handle
	if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {
		retcode = SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc); 

		// Set login timeout to 5 seconds
		if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {
				SQLSetConnectAttr(hdbc, SQL_LOGIN_TIMEOUT, (SQLPOINTER)5, 0);

			// Process data
			WCHAR pzSQLDriver[128];
			swprintf_s(pzSQLDriver, 128,
				L"Driver={SQL Server Native Client 10.0}; Server=%s; Database=master; Trusted_Connection=Yes;",
				pzServerName
			);				

			// Intialize Connection
			retcode = SQLDriverConnect( hdbc, desktopHandle, (SQLWCHAR*)pzSQLDriver,
				wcslen(pzSQLDriver), OutConnStr, 1024, &OutConnStrLen, SQL_DRIVER_NOPROMPT );

			// Allocate statement handle
			if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {               
				retcode = SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt); 

				// Process data
				WCHAR pzSQLCommand[512];
				swprintf_s(pzSQLCommand, 512,
					L"SELECT CASE WHEN db_id('%s') IS NOT NULL THEN 'TRUE' ELSE 'FALSE' END",
						pzDatabaseName
				);
				pzSQLCommand[wcslen(pzSQLCommand) + 1] = L'\0';
		
				retcode = SQLExecDirect( hstmt, (SQLWCHAR*)pzSQLCommand, SQL_NTS );				
					
				if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {						
						
					SQLBindCol( hstmt, 1, SQL_C_WCHAR, szDatabaseExist, sizeof(szDatabaseExist), &cbDatabaseExist );

					WCHAR *szResult = new WCHAR[cbDatabaseExist];

					while ((retcode = SQLFetch( hstmt )) != SQL_NO_DATA) {
						 swprintf_s(szResult, cbDatabaseExist, L"%s\n", szDatabaseExist );
						 szResult[wcslen(szResult)+1] = L'\0';
						}

					SQLFreeHandle(SQL_HANDLE_STMT, hstmt);						

					if( wcsncmp( szResult, L"TRUE", wcslen(szResult) ) > 0) {
						bResult = TRUE;
					}
					else {
						bResult = FALSE;
					}
						
				}
				SQLDisconnect(hdbc);
			}
                        SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
         }
    }
	
    SQLFreeHandle(SQL_HANDLE_ENV, henv);
}
   	
return bResult;

And then this a a preview of the contents that the thread runs for validation. If something doesn't jive, then the exitcode is generated, and returned to the thread creator, in which the thread creator generates a messagebox, and alters the dialog box.

    BOOL    bValidate = TRUE;
    BOOL    bResult = FALSE;
    DWORD   dwExitCode  = 0;
    DWORD   dwWebsitePath_Check = 0;
    DWORD   dwProjectName = 0;
    DWORD   dwFolderPath = 0;
    DWORD   dwDomainName = 0;
    DWORD   dwLicenseKey = 0;

    DWORD   dwServerName = 0;
    DWORD   dwDatabaseName = 0;
    DWORD   dwAuthMethod = 0;
    DWORD   dwAccountName = 0;
    DWORD   dwPassword = 0;

    WCHAR   *szValidKey = NULL;
    WCHAR   *szWebsitePath_Check = NULL;

    WCHAR   pzProjectType[ 64 ];
    WCHAR   pzProjectName[ MAX_PATH ];
    WCHAR   pzProjectPath[ MAX_PATH ];
    WCHAR   pzFolderPath[ MAX_PATH ];
    WCHAR   pzDomainName[ 255 ];
    WCHAR   pzLicenseKey[ 255 ];

    WCHAR   pzServerName[80];
    WCHAR   pzDatabaseName[80];
    WCHAR   pzAuthMethod[80];
    WCHAR   pzAccountName[80];
    WCHAR   pzPassword[80];

    PMAIN_RUNPROCESS pzValidate;
    pzValidate = (PMAIN_RUNPROCESS)lpParam;
    HWND cWnd               = pzValidate->m_cWnd;
    HWND hWndDlg            = pzValidate->m_hWndDlg;
    HWND lblStatusMessage   = pzValidate->m_StatusMessage;
    HWND pbProgressBar      = pzValidate->m_ProgressBar;

    PROJECT_TYPE projectType;

    // Load the Registry Class
    CA_Registry caReg;

    /////////////////////////////////////////////////////////////////////////////////////////////
// Project Type Validation

    DWORD   dwProjectType = 0;
    dwProjectType = ListView_GetNextItem( lv_ProjectCreate_ProjectType, -1, LVNI_FOCUSED );
    if ( dwProjectType == -1 ) {
        // No Selection has been made - Handle the Error in the Thread Creator
        return 1;
    }
    else {
        // A Selection has been made
        ListView_GetItemText( lv_ProjectCreate_ProjectType, dwProjectType, 0, pzProjectType, 60 );
        if ( wcsncmp( pzProjectType, L"North American Standard Edition 2012", wcslen( L"North American Standard Edition 2012" ) ) == 0 ) {
            projectType = NASE2012_STANDARD;
        }
    }

// End of Project Type Validation    /////////////////////////////////////////////////////////////////////////////////////////////
// Does the Database Exist
	BOOL bDatabaseExist = FALSE;

	CA_SQLServer_ODBC caODBC;
	bDatabaseExist = caODBC._does_SQLServer_Database_Exist_hWnd( pzServerName, pzDatabaseName );

	if ( bDatabaseExist ) {
		return 13;	
	}

	// End of Database Exist	
	/////////////////////////////////////////////////////////////////////////////////////////////
	// if SQL Authentication, validate the credentials
	BOOL bSQLValidate = FALSE;
		
	if ( !bSQL ) {
		// Validate using Windows Authentication
		bSQLValidate = caODBC._validate_SQLServer_Credentials_WinAuth( pzServerName );
		
		if ( !bSQLValidate ) {
			bValidate = FALSE;
			return 11;
		}

	}
	else {
		// Validate using SQL Authentication
		bSQLValidate = caODBC._validate_SQLServer_Credentials_SQLAuth( pzServerName, pzAccountName, pzPassword );
		
		if ( !bSQLValidate ) {
			bValidate = FALSE;
			return 12;
		}

	}
	
// End of Check Project Name
/////////////////////////////////////////////////////////////////////////////////////////////

     return dwExitCode;

Albert Holguin1-May-12 3:46

1-May-12 3:46

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.

jkirkerx1-May-12 6:59

1-May-12 6:59

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.

Albert Holguin2-May-12 5:35

I've traced it down to this

2-May-12 5:35

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).

jkirkerx1-May-12 13:55

1-May-12 13:55

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?

// Create a common memory space for threads
PMAIN_RUNPROCESS pzUpdateProcess;
pzUpdateProcess = ( PMAIN_RUNPROCESS ) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof( PMAIN_RUNPROCESS ));

// Now copy the pointers over to the heap
pzUpdateProcess->m_hWndDlg = _updates_Dialog_hWnd;
pzUpdateProcess->m_StatusMessage = lbl_Update_Dialog_StatusMessage_Label;
pzUpdateProcess->m_ProgressBar = pb_Update_Dialog_ProgressBar_Field;

// CreateThread for running Process
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);
    
    // The Code Analyst is complaining about dPAC I think where the null is, 
    SetSecurityDescriptorDacl(sa.lpSecurityDescriptor, TRUE, (PACL) ->NULL<-, FALSE);</b>

    sa.nLength = sizeof(sa);
    sa.bInheritHandle = TRUE;
    sa.nLength=sizeof(SECURITY_ATTRIBUTES);

Solved Now

jkirkerx1-May-12 17:35

1-May-12 17:35

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 ));

// Free the Heap Memory 
HeapFree( GetProcessHeap(), 0, pzValidate );
pzValidate = NULL;

Re: Solved Now

Albert Holguin1-May-12 18:22

1-May-12 18:22

By default, anything you manually create on the heap, you must manually free. Thread will only deallocate its own stack memory.

Re: Solved Now

jkirkerx1-May-12 18:33

1-May-12 18:33

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.

Re: Solved Now

Albert Holguin2-May-12 5:36

[Win32 C++] VirtualFreeEx() error after WriteProcessMemory() success. But not always.

2-May-12 5:36

Happy to help when I can... Smile | :)

_Kel_30-Apr-12 12:24

_Kel_

30-Apr-12 12:24

First time on this forum. Hello Smile | :)

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 Confused | :confused:

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.

Re: [Win32 C++] VirtualFreeEx() error after WriteProcessMemory() success. But not always.

Richard Andrew x6430-Apr-12 12:54

Richard Andrew x64

30-Apr-12 12:54

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.

Re: [Win32 C++] VirtualFreeEx() error after WriteProcessMemory() success. But not always.

_Kel_30-Apr-12 13:18

_Kel_

30-Apr-12 13:18

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.

Re: [Win32 C++] VirtualFreeEx() error after WriteProcessMemory() success. But not always.

Richard Andrew x6430-Apr-12 13:22

Richard Andrew x64

30-Apr-12 13:22

You MIGHT be able to get away with CreateThread(). I'm not sure myself.

Here's a very good post about the subject:

http://www.voyce.com/index.php/2009/12/03/dont-do-anything-in-dllmain-please/[^]

It also contains a link to an MSDN article that explains it all.

The difficult we do right away...
...the impossible takes slightly longer.

Re: [Win32 C++] VirtualFreeEx() error after WriteProcessMemory() success. But not always.

_Kel_30-Apr-12 14:30

_Kel_

30-Apr-12 14:30

*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, ...

Smile | :)

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 Wink | ;)

But I'll try this out tomorrow. Must sleep now.

Thank you very much for the informative links Thumbs Up | :thumbsup:

(vote: 4)

Feel free to add anything else you think might help.
A good night to you.

Re: [Win32 C++] VirtualFreeEx() error after WriteProcessMemory() success. But not always.

Richard Andrew x6430-Apr-12 14:43

Richard Andrew x64

30-Apr-12 14:43

I'm glad you found it useful. Good luck with your implementation.

The difficult we do right away...
...the impossible takes slightly longer.

OnInitDialog?

Le Quang Long30-Apr-12 4:38

Le Quang Long

30-Apr-12 4:38

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!

Maximilien30-Apr-12 5:03

Maximilien

30-Apr-12 5:03

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.

C++

BOOL COtherDialog::OnInitDialog()
{
  BOOL result = CDialog::OnInitDialog();

  Login loginDialog;
  if   ( loginDialog.DoModal() == IDOK )
  {
    // success continue...
  }
  else
  { 
    // login failed (either bad user/password or user canceled the login dialog.
    // for example disable some UI or close the application or something else.
  }

  return result;
}

Watched code never compiles.

Le Quang Long30-Apr-12 6:20

Le Quang Long

30-Apr-12 6:20

Thanks to your help!

David Crow30-Apr-12 6:07

David Crow

30-Apr-12 6:07

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