|
Hi,
what is difference between windows 7 and windows 2003 sever in memory heap allocation?
i have a project in visual studio 2008 C++ with using Unicode for character setting.
my project run in 2003 sever without any problem. but when i run it in windows 7, my project is breaked on a "memory allocation" line in code, like:
int i_size = 50;
wchar_t* wch = new wchar_t[i_size];
with this error message:
this maybe due to a corruption of the heap, which indicate a bug in my.exe or any of the Dlls it has loaded.
please help me.
Zo.Naderi-Iran
|
|
|
|
|
This means that the heap has been corrupted somewhere else in your code. you will need to do some debugging to discover where it happens; usually caused by overrunning a buffer somewhere.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
but my project compile and run in windows 2003 sever without any heap corruption!
what difference between windows 2003 and windows 7 ?
Zo.Naderi-Iran
|
|
|
|
|
Different is Windows 7 is giving you better security(probably)
Here is an example of how heap crashed
In one of my application I defined a string variable with the size of 20, I was reading the text from a text box. But User Put more than 20 character in that box.
It never crash in xp. But Do worse it destroy another value which has been defined right after that sting variable.
So, Its better it crashed cause at least you know where you can find the problem
|
|
|
|
|
i guess that my problem is not in size of memory allocation. However, i will check it.
but, is any other reason?
Zo.Naderi-Iran
|
|
|
|
|
zon_cpp wrote: is any other reason?
Such as what? If the heap is corrupted that means there is a piece of code that is writing somewhere in memory at an address that it does not own - it's a bug.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Just because it runs successfully in one system does not mean it is bug free. If it crashes because of heap corruption it is almost guaranteed that there is a bug in your code somewhere.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
You have a bug in your code, so run App Verifier on it and it will tell you exactly where it is happening.
--edit--
Who is the prick who one voted this?
If you are developing code and not running it through app verifier you are missing out on an opportunity to boost your products quality.
==============================
Nothing to say.
modified 22-Dec-11 13:05pm.
|
|
|
|
|
In case it's not been clear in the other messages:
A heap corruption message, and specifically that message, is telling you that somewhere, somewhen, the internal stuctures of the heap's memory management have been overwritten (corrupted). Because it did not or could not detect it at the moment it happened, heap corruptions are reported when you do something that requires the heap and that's when the run time library runs a "heap consistency check" and throws the error message.
So, it's not telling you that the particular call you did was wrong, it's just that the call was the first place it detected a previous corruption. So it's important to not focus on that particular call as the source of the problem. However, that call does give you a point in time when the corruption occurred. If you have other allocation / deallocation calls in your code, you know that the corruption occurred sometime between the last heap call and this one. That gives you a chance to narrow down the section of code to look at.
Lastly, heap corruption detection only happens in debug mode code / libraries as it is a performance hog. So, you can have had this bug for a long time and never notice it in production mode code.
|
|
|
|
|
If I had to guess, that line is probably not the problem, your problem is elsewhere. Just happens to break at that point, can you look at the call stack and see what calls happened prior to the error?
|
|
|
|
|
Hello,
I'm working on a project that deals with DLLs extensively. One bit of information that I've learned so far is that an executable will retrieve a DLL's exported function that it needs, and put the function address in the executable's Import Address Table (IAT). One question that I have is "How do functions from one DLL get called to another DLL within Windows?" Does a DLL also have an IAT in which it holds function pointers that it used from another DLL, or are these kinds of function calls also added to the executable's IAT?
Any help would be appreciated!
Thanks!
|
|
|
|
|
ryan2189 wrote: Does a DLL also have an IAT in which it holds function pointers that it used from another DLL
Yes.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
dlls and exes are essentially the same
|
|
|
|
|
I'm sure this is c++ 101
I build a class to encrypt and decrypt, but when I use the function multiple times, it changes the values of the previous buffers I stored the values in.
This is the first time I have called a function multiple times, so I'm not sure how to handle it.
CA_Encryption caEncrypt;
WCHAR *szSecretAnwser_Secure = new WCHAR[12];
szSecretAnwser_Secure = caEncrypt._encrypt_3DES(szSecretAnwser);
WCHAR *szPassword_Secure = new WCHAR[12];
szPassword_Secure = caEncrypt._encrypt_3DES(szPassword);
const int MD5_SIZE = 16;
BYTE *szPassword_Encoded = new BYTE[MD5_SIZE];
szPassword_Encoded = caEncrypt._create_MD5_Hash(szPassword);
|
|
|
|
|
I'm not sure where this code actually exists as you have not shown where in the function it is, or really what it is trying to do. however when you allocate a buffer with a new operator it creates a new buffer every time you pass that line of code (you should also delete[] them when finished with). If you want some permanent buffer then you should allocate it outside the function and pass it in as a reference on the function call. Something like:
int myfunc(buffer* pszBuffer)
{
return 1;
}
char* nbuff = new char[64];
int val = myfunc(nbuff);
delete[] nbuff;
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I didn't want to post the function because I had no idea where my poor use of buffers was. I made a class, and wrote 5 functions in it.
Normally I would of wrote 5 public functions, and do the work in private functions.
But no matter which function I run in the same class, it changes the previous buffer values to the last function ran in the class.
I think I understand now why everyone had there encryption function separated into 3 aspects.
Let me try that first.
|
|
|
|
|
jkirkerx wrote: I build a class to encrypt and decrypt, but when I use the function multiple times, it changes the values of the previous buffers I stored the values in.
What does _encrypt_3DES() look like? I don't need all of the details, just the variable that it returns and how it is declared.
"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
|
|
|
|
|
Encrypt 3DES
WCHAR* CA_Encryption::_encrypt_3DES( WCHAR *pzInputW )
{
BOOL bResult = FALSE;
WCHAR *szOutput = NULL;
HCRYPTPROV hProv;
HCRYPTKEY hKey;
ALG_ID Algid;
PBYTE pbKeyBlob = NULL;
BYTE *pbBuffer;
DWORD dwBlockLen = 0;
DWORD dwDataLen = 0;
DWORD cbData = 0;
BOOL bFinal = TRUE;
DWORD errorCode = 0;
DWORD dwResult = 0;
TCHAR szBase64[80];
DWORD cbKeyLen = 24;
int iCharA = WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, NULL, 0, NULL, NULL);
char *szInputA = new char[iCharA];
WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, szInputA, iCharA, NULL, NULL);
keyBlob192.hdr.bType = PLAINTEXTKEYBLOB;
keyBlob192.hdr.bVersion = CUR_BLOB_VERSION;
keyBlob192.hdr.reserved = 0;
keyBlob192.hdr.aiKeyAlg = CALG_3DES;
keyBlob192.cbKeySize = 24;
ZeroMemory(keyBlob192.rgbKeyData, 24);
CopyMemory(keyBlob192.rgbKeyData, KEY_192, cbKeyLen > 24 ? 24 : cbKeyLen);
bResult = CryptAcquireContextW( &hProv, 0, MS_ENHANCED_PROV, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT);
bResult = CryptImportKey(hProv, (BYTE*)&keyBlob192, sizeof(keyBlob192), 0, CRYPT_EXPORTABLE, &hKey);
bResult = CryptSetKeyParam(hKey, KP_IV, IV_64, 0);
dwDataLen = sizeof(ALG_ID);
cbData = sizeof(szInputA);
if (!CryptGetKeyParam(hKey, KP_ALGID, (BYTE *)&Algid, &dwDataLen, 0))
return 0;
if (GET_ALG_TYPE(Algid) != ALG_TYPE_STREAM) {
dwDataLen = sizeof(DWORD);
if (!CryptGetKeyParam(hKey, KP_BLOCKLEN, (BYTE *)&dwBlockLen, &dwDataLen, 0))
return 0;
dwDataLen = ((cbData + dwBlockLen - 1) / dwBlockLen) * dwBlockLen;
if (!(pbBuffer = (BYTE *)LocalAlloc(LMEM_FIXED, dwDataLen)))
return 0;
}
else {
if (!(pbBuffer = (BYTE *)LocalAlloc(LMEM_FIXED, cbData)))
return 0;
}
CopyMemory(pbBuffer, szInputA, cbData);
if (!CryptEncrypt(hKey, 0, bFinal, 0, pbBuffer, &cbData, dwDataLen)) {
DWORD dwError = GetLastError();
if(ERROR_MORE_DATA == dwError) {
DWORD dwSizeNeeded = cbData;
CopyMemory( pbBuffer, szInputA, cbData );
bResult = CryptEncrypt(hKey, 0, FALSE, 0, pbBuffer, &dwSizeNeeded, dwDataLen);
}
LocalFree(pbBuffer);
return 0;
}
if(CryptBinaryToString(pbBuffer, 8, CRYPT_STRING_BASE64, NULL, &dwResult)) {
CryptBinaryToString(pbBuffer, 8, CRYPT_STRING_BASE64, szBase64, &dwResult);
szBase64[dwResult] = 0;
szOutput = (WCHAR*)szBase64;
szOutput[wcslen(szOutput)+1] = L'\0';
}
SecureZeroMemory( keyBlob64.rgbKeyData, 8 );
SecureZeroMemory( pbBuffer, sizeof(pbBuffer) );
delete [] szInputA;
CryptDestroyKey(hKey);
CryptReleaseContext(hProv, 0);
return szOutput;
}
Hash
BYTE* CA_Encryption::_create_MD5_Hash( WCHAR *pzInputW )
{
BOOL bResult = FALSE;
HCRYPTPROV hProv;
HCRYPTHASH hHash;
const int MD5_SIZE = 16;
static BYTE hash[MD5_SIZE];
DWORD hash_size = sizeof(hash);
int iChar = WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, NULL, 0, NULL, NULL);
char *szInputA = new char[iChar];
WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, szInputA, iChar, NULL, NULL);
DWORD dwBufferSize = 0;
DWORD dwPasswordLen = strlen((char *)szInputA);
bResult = CryptAcquireContextW( &hProv, NULL, MS_STRONG_PROV, PROV_RSA_FULL, 0);
bResult = CryptCreateHash( hProv, CALG_MD5, 0, 0, &hHash );
bResult = CryptHashData( hHash, (BYTE*)szInputA, dwPasswordLen, 0 );
bResult = CryptGetHashParam( hHash, HP_HASHVAL, hash, &hash_size, 0 );
delete [] szInputA;
CryptDestroyHash(hHash);
CryptReleaseContext(hProv, 0);
return hash;
}
|
|
|
|
|
As I suspected, szOutput is an auto (i.e., local) variable. Under the right conditions, it will point to szBase64, another auto variable. It sounds as though you need to call _encrypt_3DES() with an additional argument: a buffer to store the result in.
"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
|
|
|
|
|
Thanks for checking it out Dave.
I even experimented with changing the name of szOutput to unique names, but it still did the same thing.
I think that's why all the examples I saw had the base64 part in a separate function.
|
|
|
|
|
Thanks for your help. You were right on the money.
I learned alot on this one. Sort of like the post above this one. When you allocate memory, you have to have the exact right size including the null terminator.
So now I call it twice, once to get the size I need, and again with the right size.
I still have 1 bug left, I get 2 extra spaces in the SQL database column that are squares, I may have double null terminators or something. The -2 was just an experiment.
DWORD dwSecretAnwser;
caEncrypt._encrypt_3DES(szSecretAnwser, dwSecretAnwser);
WCHAR *szSecretAnwser_Secure = new WCHAR[dwSecretAnwser];
szSecretAnwser_Secure = caEncrypt._encrypt_3DES(szSecretAnwser, dwSecretAnwser);
WCHAR* CA_Encryption::_encrypt_3DES( WCHAR *pzInputW, DWORD &dwOutput )
{
BOOL bResult = FALSE;
HCRYPTPROV hProv;
HCRYPTKEY hKey;
ALG_ID Algid;
PBYTE pbKeyBlob = NULL;
BYTE *pbBuffer;
DWORD dwBlockLen = 0;
DWORD dwDataLen = 0;
DWORD cbData;
BOOL bFinal = TRUE;
DWORD errorCode = 0;
TCHAR *szBase64 = NULL;
DWORD dwResult;
DWORD cbKeyLen = sizeof(KEY_192);
int iCharA = (WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, NULL, 0, NULL, NULL) - 1);
char *szInputA = new char[iCharA];
WideCharToMultiByte(CP_UTF8, 0, pzInputW, -1, szInputA, iCharA, NULL, NULL);
keyBlob192.hdr.bType = PLAINTEXTKEYBLOB;
keyBlob192.hdr.bVersion = CUR_BLOB_VERSION;
keyBlob192.hdr.reserved = 0;
keyBlob192.hdr.aiKeyAlg = CALG_3DES;
keyBlob192.cbKeySize = sizeof(KEY_192);
CopyMemory(keyBlob192.rgbKeyData, KEY_192, cbKeyLen> sizeof(keyBlob192) ? sizeof(keyBlob192) : cbKeyLen);
bResult = CryptAcquireContextW( &hProv, 0, MS_ENHANCED_PROV, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT);
bResult = CryptImportKey(hProv, (BYTE*)&keyBlob192, sizeof(keyBlob192), 0, CRYPT_EXPORTABLE, &hKey);
bResult = CryptSetKeyParam(hKey, KP_IV, IV_192, 0);
dwDataLen = sizeof(ALG_ID);
cbData = iCharA;
if (!CryptGetKeyParam(hKey, KP_ALGID, (BYTE *)&Algid, &dwDataLen, 0))
return 0;
if (GET_ALG_TYPE(Algid) != ALG_TYPE_STREAM) {
dwDataLen = sizeof(DWORD);
if (!CryptGetKeyParam(hKey, KP_BLOCKLEN, (BYTE *)&dwBlockLen, &dwDataLen, 0))
return 0;
dwDataLen = ((cbData + dwBlockLen - 1) / dwBlockLen) * dwBlockLen;
if (!(pbBuffer = (BYTE *)LocalAlloc(LMEM_FIXED, dwDataLen)))
return 0;
}
else {
if (!(pbBuffer = (BYTE *)LocalAlloc(LMEM_FIXED, cbData)))
return 0;
}
CopyMemory(pbBuffer, szInputA, cbData);
if (!CryptEncrypt(hKey, 0, bFinal, 0, pbBuffer, &cbData, dwDataLen)) {
LocalFree(pbBuffer);
return 0;
}
SecureZeroMemory( keyBlob192.rgbKeyData, sizeof(keyBlob192.rgbKeyData) );
delete [] szInputA;
CryptDestroyKey(hKey);
CryptReleaseContext(hProv, 0);
if(CryptBinaryToString((BYTE*)pbBuffer, cbData, CRYPT_STRING_BASE64, NULL, &dwResult)) {
if ((dwOutput > 0 ) && (dwOutput < 4096)) {
szBase64 = new TCHAR[dwResult];
CryptBinaryToString((BYTE*)pbBuffer, cbData, CRYPT_STRING_BASE64, szBase64, &dwResult);
dwOutput = dwResult;
szBase64[dwResult-2] = 0;
return szBase64;
}
else {
dwOutput = dwResult;
return L'\0';
}
}
else {
dwOutput = dwResult;
return L'\0';
}
}
|
|
|
|
|
Hi,
Does anyone know of a compiler that will run under Windows 7 (64 bit) but will compile 16 bit DOS based code? I used to use MSVC 1.52 on XP 32 bit but it will not run on a 64 bit platform. I tried running it under Virtual PC but it is too unstable (it regularly deleted the contents of my source files which is not much fun).
Thanks 
|
|
|
|
|
A quick search gives promising results for running Turbo C using DOSBox: I've not tried that, however.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I don't often use Windows 7 so I might be wrong on this, but as far as I know it comes with a built in 32 bit Windows XP virtual machine? MSVC 1.52 might work in that.
Personally I use Microsoft C 6.0 in DosBox[^] and MSVC 1.52 in a Windows 2000 guest OS with VirtualBox[^], both works.
modified 13-Sep-18 21:01pm.
|
|
|
|
|
Thanks for the reply.
Win 7/64 Pro does come with XP virtual machine but unfortunately I only have the Home edition which does not. I thought about upgrading but its too much hassle re-installing everything.
I have a copy of Microsoft C 6.0 somewhere so I think I will give that a go in DosBox.
Can you advise how I install it in DosBox please.
Thanks for the tip.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
