|
There is a call somewhere in your program to this function. The program loader checks all calls at initialisation to ensure the program can execute correctly. It appears that your friend's PC must have a very old (i.e. non Unicode) version of the system libraries.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
The Requirements for RegGetValue are given by MS as:
Minimum supported client: Windows Vista, Windows XP Professional x64 Edition
Minimum supported server Windows Server 2008, Windows Server 2003 with SP1
Is your test running on one of these?
|
|
|
|
|
I thought does was an old function available since Windows 2000.
Any idea how to get a previous older function?
|
|
|
|
|
You can use the RegQueryValueEx function which is available in older OSs.
|
|
|
|
|
You may like to look at RegQueryValueEx()[^].
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
I'm trying to create a SafeArray of Variants (min 1000 and max 6000 elements). Initially the array is not going to contain the variants, they will be added later on. Here's the sample code -
<code>
SAFEARRAY *psfaResult = NULL;
SAFEARRAYBOUND rgsabound[1];
rgsabound[0].lLbound = 0;
rgsabound[0].cElements = ElementCount;
psfaResult = SafeArrayCreate(VT_VARIANT, 1, rgsabound);
if(psfaResult == NULL)
{
/*
error handling
*/
}
</code>
What happens is, frequently an access violaion exception is thrown during the creation causing the code to crash. I have a snapshot of the callstack when this problem occurs, but I guess I'll have to type it out -
First chance exception 0xC0000005 ACCESS_VIOLATION occurred at 0x7C911689, read of address 0x00000000 at 0x7C911689 (in C:\WINDOWS\system32\ntdll.dll)
0x7C911689 RtlInitializeCriticalSection + Ox6C in C:\WINDOWS\system32\ntdll.dll
0x7C91A3F5 RtlReAllocateHeap + Ox855 in C:\WINDOWS\system32\ntdll.dll
0x7C911937 RtlInitializeCriticalSection + Ox31A in C:\WINDOWS\system32\ntdll.dll
0x774FD03B IsValidIid + OxFA in C:\WINDOWS\system32\ole32.dll
0x7712AA1B SafeArrayAllocData + Ox3B in C:\WINDOWS\system32\oleaut32.dll
0x7712AAE3 SafeArrayCreate + Ox8E in C:\WINDOWS\system32\oleaut32.dll
I have attempted an alternative of using CComSafeArray as well, which internally uses the same route, hence in vain. The issue occurs only in release mode, 5/10 times.
My feeling is that this is an effect and the cause is elsewhere in the code. However, what I am looking out for is, directions to search the probable causes.
Any insight into the problem will be helpful! Thanks!
|
|
|
|
|
There is nothing wrong with the code. The only place where a problem might occur is the ElementCount variable, if it's zero. I suppose since cElements is unsigned, using a negative value would not present a problem and return E_OUTOFMEMORY. I don't know how the API will respond to that, but if you have made sure it's within valid bounds, the code should work as written.
Edit: Do you use your compilers highest warning level?
|
|
|
|
|
Actually I felt the same at first, so I logged the count. The count is as expected when the exception occurs.
|
|
|
|
|
Hi,
I'm using LibTiff to write TIFF files (from multiple threads) in C++, and getting
the following error message:
"Probable I/O race condition detected while copying memory. The I/O
package is not thread safe by default. In multithreaded applications,
a stream must be accessed in a thread-safe way, such as a thread-safe
wrapper returned by TeaxtReader´s or TextWriters´s Synchronized methods.
This also applies to classes like StreamWriter and StreamReader"
(The C++ is being called from a C# GUI, which accounts for the .NET class names.)
The weird thing is that the LibTiff call is in a critical section, which
(theoretically) should avoid race conditions:
DLLEXPORT int writeVariableImage (HBITMAP staticBlackLayer, HBITMAP varLayer,
VariableObject* varObj, int numVarObjects,
char* fileName)
{
if (!criticalSectionInitialized)
{
InitializeCriticalSection (&cs);
criticalSectionInitialized = true;
}
EnterCriticalSection(&cs);
try
{
if (!copyBitmap (varLayer, staticBlackLayer))
throw 666;
HDC memDc = CreateCompatibleDC (NULL);
HGDIOBJ Obmp = SelectObject(memDc, varLayer);
if (!memDc || !Obmp)
throw 666;
for (int i = 0; i < numVarObjects; ++i)
drawVariableObject (memDc, &varObj [i]);
invertLayer (memDc, varLayer);
writeToTiffFile (varLayer, fileName);
if (!SelectObject (memDc, Obmp) ||
!DeleteDC (memDc))
throw 666;
}
catch (...)
{
DWORD err = GetLastError ();
if (err)
{
LPTSTR s;
FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
NULL, err, 0, (LPTSTR)&s, 0, NULL);
MessageBox (NULL, s, L"Error", 0);
LocalFree (s);
}
LeaveCriticalSection(&cs);
return 0;
}
LeaveCriticalSection(&cs);
return 1;
}
The other oddity is that the error only shows up on 1 out of the 4 computers it's
been tried on. (The computer that shows the error has 4 cores, the others, 2.)
Any ideas what could be causing this, or how to avoid it? Thanks!
|
|
|
|
|
Some ideas to help you track down problem.
1. You seem to have the 'source code'. I would move the critical section initialization outside this function and make damn sure it is already done before ANY thead has a achance to call the function.
2. Make sure no two calls are trying to write to the same file.
3. Increment a local variable along the way - print out its value in the exception handler to get an idea WHERE you had a problem. They currently thow 666 everywhere - not too easy to tell what the real problem is when that is being done.
I would not try too hard to figure out what is wrong without the changes I suggest above, which is what I would do to allow me to diagnose the actual problem.
|
|
|
|
|
Great suggestions! Thanks! (I especially like #1; multiple threads could hit this at once.)
|
|
|
|
|
On my XP machine with VS6, I have a dialog with a datetime picker control. I also added a manifest.xml file to the project so that it would be themed. When I run it, the calendar that pops up is pleasant to look at: lots of contrasting colors such as blue header where month and year are, blue weekday names with underline, black dates for current month and light gray for previous/next month, red ring around today. When I do the same thing on my Windows 7 machine with VS2005, it is a blah calendar (e.g., little to no colors, no underline). Do I need to add something or turn some option on in order for the calendar control to look better?
Thanks.
- DC
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I've just tried this on my VC 2010 Express, Windows 7 system. What you describe for XP sounds like what I get when runnng without the manifest settings for v 6 common controls. The themed version (with no colours) seems to be the default, and I could not see anything to change the default colour scheme, although you can modify certain parts.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
Windows Xp,Visual studio 6 service pack 3, Win32 c++dll
Have a C++ driver and it calls the dll in a loop. The code executes once and crashes before it gets around to the top of the loop. So...I would like to know how to step into the code of the dll. I have the code in a different project.
One time i accidentally did this so i know it can be done BUT i don't recall how.
Googling is not very enlightening atm
|
|
|
|
|
If it's your DLL then just create a debug version, link to it and run your program through the debugger. Set a breakpoint at some appropriate location in order to step into the DLL.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
AND if the DLL is dynamically, laoded, go to the part of the development environment that lets you set up DLL to be loaded early, otherwise your breakpoint will start off disabled.
Worst case, temporarily hard code a DebugBreak in the loop and when that is hit, the system will drop you into the debugger.
|
|
|
|
|
Very interesting, but I think you should direct your comments to the OP.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
If your calling program is managed code and the DLL is unmanaged, you need to go to the project properties, Debug tab, and click the "Enable unmanaged code debugging" check box.
|
|
|
|
|
Trying to compile a small library but getting this error message in the header file. The header contains one function where one of the parameters is of type 'BOOL'. Using Visual C++ 6.
Any ideas how to get rid of this?
|
|
|
|
|
include windows.h before such header.
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]
|
|
|
|
|
Or add it on top of the header file itself...
|
|
|
|
|
Really I can't understand univoters...
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]
|
|
|
|
|
CPallini wrote: Really I can't understand univoters...
Smile
Even this is true in most parts, isn't it ?!
...byte till it megahertz...
|
|
|
|
|
bleedingfingers wrote: Even this is true in most parts, isn't it ?!
Yes, I think that's true: you can't understand voters...
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]
|
|
|
|
|
CPallini wrote: Really I can't understand univoters...
Currently, this is true for me!
|
|
|
|