We have a program at work that keeps crashing. All it does is take 5 digital pictures and save them on the drive as BMPs.
The 5 pictures though are compiled - for instance if you wanted to scan you car each frame would be 1 bmp. When the camera moved...another bmp. The final bmp is the sum total of all the bmps crammed together side by side. Not very efficient and not the best way....but hey I didn't write the code.
Everyone says its crashing because of video memory, and/or system memory. But the thing has 698 MB free according to Windows and AFAIK you cannot get a pointer to texture memory under Windows w/o calling out to a third party driver running at a diff privilege level than your app. There is a big diference between video memory as we all know it and video card memory as in 256 MB of video mem. 256 MB of video mem is not the memory that the computer scans and displays on the screen. Rather it is video card texture memory and can only be accessed via drivers that map the texture memory into your app's address space or via DirectX which uses a driver...hence the HAL.
In fact if Windows XP/NT/2000 did let you access video memory directly via a pointer what a mess that would be. So my assumption is that the privilege level of the video memory segment selector or even perhaps the LFB has been upped somewhat to prevent direct access to it by lower privilege programs. Am I way off here?
The problem is not in the data being written to disk, it's in the image inside of the window. After a while it will begin to flash between the last known image and the current live one. After about 2 images like this...the thing will catch and error, crash, and say it is generating a log...which it doesn't. Windows does not even come up with an error which makes it hard to diagnose. This does not always occur after 2 scans....but usually when it starts flickering between 2 or 3 images....it CTDs. Note though that even though the program CTD's and/or closes and aborts....the bmp is correctly written to disk which shows me that the buffer containing the bmps is not corrupted...rather is has something to do with the image being displayed inside of the window, or the real time image.
Also if you close the dialog box that starts the digital camera and then reopen the dialog...the flashing stops - which points to a client HDC problem I think.
To me it sounds like an error in the code whilst accessing the HDC of the client window. To write to a client window you must retrieve the HDC and either a pointer to the buffer the client uses or use API calls to draw inside of the buffer pixel by pixel. If this pointer to the HDC or to the buffer is corrupted via another problem in memory or a wild pointer....it's possible the program could cause a CTD and on 98 probably a BSOD.
This program is running on Win2K, note: it worked fine on Win98.