how to read a file from hex editor and find equivalent ASCII values in c++ [closed] - c++

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
i have a file in hex looking like below
9C CB CB 8D 13 75 D2 11 91 58 00 C0 4F 79 56 A4
60 00 00 00 92 02 00 00 40 1F 00 00 80 14 00 00
A4 08 00 00 90 02 00 00 A0 09 01 00 40 AE 00 00
E4 27 00 00 90 02 00 00 A0 09 01 00 FC 7A 00 00
84 31 01 00 CF 01 00 00 A0 09 01 00 14 A7 00 00
24 3B 02 00 75 02 00 00 A0 09 01 00 50 8D 00 00
C4 44 03 00 14 02 00 00 A0 09 01 00 20 35 00 00
64 4E 04 00 C8 00 00 00 90 02 00 00 E8 03 00 00
00 00 00 00 00 08 00 00 CA 01 00 00 A4 00 00 00
first sixteen bytes (9C CB CB 8D 13 75 D2 11 91 58 00 C0 4F 79 56 A4) are showing header of my file.

This will convert the hexadecimal input to characters, and print them out (though the numbers 80 and greater won't actually be ASCII, since they're outside the range defined by ASCII):
#include <algorithm>
#include <iostream>
#include <iterator>
#include <string>
int main() {
std::transform(std::istream_iterator<std::string>(std::cin),
std::istream_iterator<std::string>(),
std::ostream_iterator<char>(std::cout),
[](std::string const &in) {
return (char) strtol(in.c_str(), NULL, 16);
});
}
I'm not sure how much good that'll do for you, but it seems to be what you're asking, and without more information on what you really want, it's about as good as I think anybody can probably do.

Related

Finding 3 specific byte values within a set number of bytes of each other

I extracted a large number of bytes from an ISO into Notepad++ and ended up with 131,076 characters worth of space-separated values.
I would like to find where there occur at least three specific values within a fixed number of bytes of each other.
As an example, I would like the values 11, 12, and B4 to be highlighted if they are within 18 bytes (=53 characters) of each other, in this:
03 00 1F 06 01 15 12 10 00 00 00 00 00 05 00 00 00 00
04 00 3B 06 02 25 02 11 00 03 06 00 00 85 65 88 00 00
05 00 24 06 11 15 12 10 00 06 09 00 00 0C 7C 1A 00 00
06 00 41 04 12 24 01 11 00 00 00 00 00 42 00 00 00 00
07 00 26 03 11 15 12 01 00 00 00 00 00 B4 00 00 00 00
08 00 0E 06 10 15 11 11 00 08 00 00 00 CB 7C 00 00 00
09 00 0A 00 10 11 01 21 00 06 00 00 00 68 BD 00 00 00
0A 00 5B 07 10 10 20 11 00 00 00 00 00 3D 00 00 00 00
0B 00 40 00 12 24 01 12 00 00 00 00 00 00 00 00 00 00
The required result is the following, where the square brackets indicate which values need to be highlighted:
03 00 1F 06 01 15 12 10 00 00 00 00 00 05 00 00 00 00
04 00 3B 06 02 25 02 11 00 03 06 00 00 85 65 88 00 00
05 00 24 06 11 15 12 10 00 06 09 00 00 0C 7C 1A 00 00
06 00 41 04 12 24 01 11 00 00 00 00 00 42 00 00 00 00
07 00 26 03[11]15[12]01 00 00 00 00 00[B4]00 00 00 00
08 00 0E 06 10 15 11 11 00 08 00 00 00 CB 7C 00 00 00
09 00 0A 00 10 11 01 21 00 06 00 00 00 68 BD 00 00 00
0A 00 5B 07 10 10 20 11 00 00 00 00 00 3D 00 00 00 00
0B 00 40 00 12 24 01 12 00 00 00 00 00 00 00 00 00 00
Can this be done? (If not, is it possible to do so for only two values?)
Notes:
The values can appear in any order.
I don't want to clear the data around the values, just highlight them or make them stand out so that I can track and use the values to understand how a certain table works within an ISO.
The above example contains line-feeds/carriage returns just for readability. The actual data doesn't contain any - all the values are space-separated only.

Formatting a file using regex

Spent some time trying to format a file with roughly 5,000 hex values, however with no luck. For example
1b 00 10 50 a3 bb 0e b7 ff ff 00 00 00 00 09 00
01 02 00 01 00 85 03 0e 00 00 00 55 0e 04 66 03
2a 38 32 80 00 0e 00 2f c2
1b 00 10 50 a3 bb 0e b7 ff ff 00 00 00 00 09 00
01 02 00 01 00 85 03 2b 00 00 00 55 2b 04 58 28
2a 39 32 80 00 01 00 12 57 4d 32 34 30 20 41 43
20 56 65 72 2e 41 00 00 23 06 00 0a 23 06 00 0a
01 00 00 c0 14 56
1b 00 30 a6 59 b8 0e b7 ff ff 00 00 00 00 09 00
00 02 00 01 00 04 03 0d 00 00 00 55 0d 04 33 2a
03 3a 32 40 00 0e be 40
1b 00 f0 01 f1 b6 0e b7 ff ff 00 00 00 00 09 00
00 02 00 01 00 04 03 0e 00 00 00 55 0e 04 66 2a
00 3b 32 40 00 01 05 c9 b1
and so on..
I need to format in the following matter:
1b 00 10 50 a3 bb 0e b7 ff ff 00 00 00 00 09 00 01 02 00 01 00 85 03 0e 00 00 00 55 0e 04 66 03 2a 38 32 80 00 0e 00 2f c2
1b 00 10 50 a3 bb 0e b7 ff ff 00 00 00 00 09 00 01 02 00 01 00 85 03 2b 00 00 00 55 2b 04 58 28 2a 39 32 80 00 01 00 12 57 4d 32 34 30 20 41 43 20 56 65 72 2e 41 00 00 23 06 00 0a 23 06 00 0a 01 00 00 c0 14 56
1b 00 30 a6 59 b8 0e b7 ff ff 00 00 00 00 09 00 00 02 00 01 00 04 03 0d 00 00 00 55 0d 04 33 2a 03 3a 32 40 00 0e be 40
1b 00 f0 01 f1 b6 0e b7 ff ff 00 00 00 00 09 00 00 02 00 01 00 04 03 0e 00 00 00 55 0e 04 66 2a 00 3b 32 40 00 01 05 c9 b1
Basically put each hex block into one line still separated by space. For the life of me, i cannot figure out the regular expression to format this for me. I have tried different expressions but everything i tried either removes the line that separates hex blocks or grabs a last character of the line instead of the actual \n.
Maybe there is a better way of formatting files other than using regex
Please try regex: (?!\n\n)\n
Demo

(VS15 C++) Got a Visual Leak Detector report, but what now?

because of some (strange) problems in my C++-project I used Visual Leak Detector (for the first time), to check the project on memory leaks.
So I got i.a. the follwoing reports:
WARNING: Visual Leak Detector detected memory leaks!
---------- Block 4 at 0x004D07B0: 200 bytes ----------
Leak Hash: 0xD2D1B4A0, Count: 1, Total 200 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
28 75 14 03 00 00 00 00 01 00 00 00 00 00 00 00 (u...... ........
9A 99 99 99 99 99 B9 3F 50 00 00 00 0A 00 00 00 .......? P.......
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 74 3F 14 00 00 00 BA FF FF FF {..G.zt? ........
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 84 3F 00 00 00 00 64 00 00 00 {..G.z.? ....d...
00 00 00 00 01 00 00 00 14 00 00 00 46 00 00 00 ........ ....F...
00 00 00 00 64 00 00 00 00 00 00 00 F4 01 00 00 ....d... ........
01 00 00 00 B8 E2 13 03 F0 AD 18 03 00 00 00 00 ........ ........
C8 E2 13 03 C8 AB 18 03 00 00 00 00 78 E3 13 03 ........ ....x...
B8 AC 18 03 00 00 00 00 68 E2 13 03 E8 AC 18 03 ........ h.......
00 00 00 00 14 00 00 00 01 00 00 00 64 00 00 00 ........ ....d...
01 00 00 00 00 00 00 00 ........ ........
---------- Block 20 at 0x004D0880: 200 bytes ----------
Leak Hash: 0xD2D1B4A0, Count: 1, Total 200 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
78 74 14 03 00 00 00 00 01 00 00 00 00 00 00 00 xt...... ........
9A 99 99 99 99 99 B9 3F 50 00 00 00 0A 00 00 00 .......? P.......
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 74 3F 14 00 00 00 BA FF FF FF {..G.zt? ........
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 84 3F 00 00 00 00 64 00 00 00 {..G.z.? ....d...
00 00 00 00 01 00 00 00 14 00 00 00 46 00 00 00 ........ ....F...
00 00 00 00 64 00 00 00 00 00 00 00 F4 01 00 00 ....d... ........
01 00 00 00 38 E2 13 03 00 F0 15 03 00 00 00 00 ....8... ........
B8 E1 13 03 88 00 7F 05 00 00 00 00 08 E2 13 03 ........ ........
20 FF 7E 05 00 00 00 00 E8 E1 13 03 80 FF 7E 05 ..~..... ......~.
00 00 00 00 14 00 00 00 01 00 00 00 64 00 00 00 ........ ....d...
01 00 00 00 00 00 00 00 ........ ........
---------- Block 31 at 0x0053E1B8: 72 bytes ----------
Leak Hash: 0x3F88029B, Count: 1, Total 72 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
60 BC 55 00 40 3E 80 05 A0 3F 80 05 A0 3F 80 05 `.U.#>.. .?...?..
60 BB 55 00 20 34 18 03 00 00 00 00 00 00 00 00 `.U..4.. ........
00 00 00 00 20 00 00 00 2F 00 00 00 80 BC 55 00 ........ /.....U.
00 2E 18 03 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
20 00 00 00 2F 00 00 00 ..../... ........
---------- Block 33 at 0x0055BB60: 8 bytes ----------
Leak Hash: 0xA49C5AA6, Count: 1, Total 8 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
C8 E1 53 00 00 00 00 00
..S..... ........
//And many more...
Unfortunatly I do not understand, what VLD wants to say is the problem.
With a double-click on the "f:\dd..."-lines it should set my courser to the line with the problem, shouldn´t it? But it dosen´t.
My question is now: How do I get to the area of the problem or in other words "how do I read these reports"?
In addition:
I use Visual Studio 2015
The project is a C++ Windows Forms Project
I included the vld.h in the additional includes and the lib-directory to the additional libraries of the project
In the main() I use #include <vld.h> and _CrtDumpMemoryLeaks();
EDIT:
My Main (a reduced version, but gives similar reports):
//some class-includes
#include <vld.h>
using namespace System;
using namespace System::Windows::Forms;
using namespace std;
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
[STAThread]
void Main()
{
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Experiment* experiment = new Experiment();
Experiment_List* running_experiments = new Experiment_List();
while(!experiment->end) {
experiment= new Experiment();
LASS::MainWindow form(experiment, running_experiments);
form.ShowDialog();
if(!experiment->end){
running_experiments->register_experiment(experiment);
}
}
running_experimente->end_all();
_CrtDumpMemoryLeaks();
exit(0);
}
Unfortunatley there are about 40 classes, that I do not want to post...
I don't know where the problem exact is.
For me, it helps to run the program in RELEASE Mode, instead of DEBUG mode.
I suppose, my problem is the handling of managed and unmanaged code together.
I have unmanaged code inside managed code.
It seams as if CLR use a different new operator in Debug mode. Not as conform as the c++ standard.
According to: Using push_back() for STL List in C++ causes Access Violation, Crash
If you malloc() a C++ class, no constructors will be called for any of
that class's fields
And the VS will step into a constructor in class new_scalar.cpp.
Folks say that is depending of the Visual Leak Detector (VLD). You use them in your includes.
In the End, try to distinguish your code with
#pragma managed
and
#pragma unmanaged
And run in RELEASE mode.

Could this be a false positive memory leak report?

I am testing my dll that I created. It in turn use several other dlls. My Dll tester application reports memory leaks when I start the test application and exit without doing anything except loading dll using LoadLibrary. It doesn't show the exact files in my dll source code. There are no leaks if I don't load the dll. It is an MFC dll and has App class. I removed everything from the dll's app class so it does nothing but I still get memory leaks report when I load it. I created another set of dummy dll and test application but that doesn't report any leaks so it has to do with my original dll, perhaps its linkage with other dlls?
I have tried using _crtBreakAlloc = {allocation_#}; technique but it doesn't stop the debugger either. I am quite lost if this memory leak is real. I see from documentation it can report false positive. Could this be false positive just because my dll is linked to bunch of other dlls? I can't think of anything else because I have commented out all functionality from dll.
Here is the memory leak erros
Detected memory leaks!
Dumping objects ->
{250} client block at 0x00567E40, subtype c0, 64 bytes long.
a CDynLinkLibrary object at $00567E40, 64 bytes long
a CDynLinkLibrary object at $00567E40, 64 bytes long
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {244} normal block at 0x00567C20, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {243} normal block at 0x00567BC8, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {242} normal block at 0x00567B58, 52 bytes long.
Data: < x > E4 B8 07 78 11 00 00 00 11 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {241} normal block at 0x00566C08, 40 bytes long.
Data: < x > E4 B8 07 78 0B 00 00 00 0B 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {240} normal block at 0x00566BA8, 32 bytes long.
Data: < x > E4 B8 07 78 07 00 00 00 07 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {239} normal block at 0x00566B50, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {238} normal block at 0x00566AE0, 46 bytes long.
Data: < x > E4 B8 07 78 0E 00 00 00 0E 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {237} normal block at 0x00566A70, 48 bytes long.
Data: < x > E4 B8 07 78 0F 00 00 00 0F 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {235} normal block at 0x005676B0, 42 bytes long.
Data: < x > E4 B8 07 78 0C 00 00 00 0C 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {234} normal block at 0x00567658, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {233} normal block at 0x00567600, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {232} normal block at 0x00567590, 50 bytes long.
Data: < x > E4 B8 07 78 10 00 00 00 10 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {231} normal block at 0x00567538, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {230} normal block at 0x005674E0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {229} normal block at 0x00567488, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {228} normal block at 0x00567430, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {227} normal block at 0x005673D8, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {226} normal block at 0x00567380, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {225} normal block at 0x00567328, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {224} normal block at 0x005672C0, 40 bytes long.
Data: < x > E4 B8 07 78 0B 00 00 00 0B 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {223} normal block at 0x00567268, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {222} normal block at 0x00567200, 44 bytes long.
Data: < x > E4 B8 07 78 0D 00 00 00 0D 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {221} normal block at 0x00567198, 38 bytes long.
Data: < x > E4 B8 07 78 0A 00 00 00 0A 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {220} normal block at 0x00567140, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {219} normal block at 0x005670E8, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {218} normal block at 0x00567080, 38 bytes long.
Data: < x > E4 B8 07 78 0A 00 00 00 0A 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {217} normal block at 0x00567028, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {216} normal block at 0x00566FD0, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {215} normal block at 0x00566F78, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {214} normal block at 0x00566F18, 36 bytes long.
Data: < x > E4 B8 07 78 09 00 00 00 09 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {213} normal block at 0x00566EC0, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {212} normal block at 0x00566E68, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {211} normal block at 0x00566E10, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {210} normal block at 0x00566DB8, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {209} normal block at 0x00566D60, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {208} normal block at 0x00566D08, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {207} normal block at 0x00566CB0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {206} normal block at 0x00561918, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {205} normal block at 0x005618C0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {204} normal block at 0x00561868, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {202} normal block at 0x005669F8, 60 bytes long.
Data: < x > E4 B8 07 78 15 00 00 00 15 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {201} normal block at 0x00566988, 46 bytes long.
Data: < x > E4 B8 07 78 0E 00 00 00 0E 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {200} normal block at 0x00566920, 42 bytes long.
Data: < x > E4 B8 07 78 0C 00 00 00 0C 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {199} normal block at 0x005668C8, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {198} normal block at 0x00566868, 32 bytes long.
Data: < x > E4 B8 07 78 07 00 00 00 07 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {197} normal block at 0x00566800, 44 bytes long.
Data: < x > E4 B8 07 78 0D 00 00 00 0D 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {196} normal block at 0x00566790, 50 bytes long.
Data: < x > E4 B8 07 78 10 00 00 00 10 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {195} normal block at 0x00566718, 60 bytes long.
Data: < x > E4 B8 07 78 15 00 00 00 15 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {194} normal block at 0x005666C0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {193} normal block at 0x00566040, 48 bytes long.
Data: < x > E4 B8 07 78 0F 00 00 00 0F 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {192} normal block at 0x00561C98, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {81} normal block at 0x00561BA0, 32 bytes long.
Data: < x > E4 B8 07 78 07 00 00 00 07 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {80} normal block at 0x00561B48, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {79} normal block at 0x00561AE0, 44 bytes long.
Data: < x > E4 B8 07 78 0D 00 00 00 0D 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {78} normal block at 0x00561A80, 34 bytes long.
Data: < x > E4 B8 07 78 08 00 00 00 08 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {77} normal block at 0x00561A20, 30 bytes long.
Data: < x > E4 B8 07 78 06 00 00 00 06 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {76} normal block at 0x005613D0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {75} normal block at 0x005619A8, 56 bytes long.
Data: < x > E4 B8 07 78 13 00 00 00 13 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {74} normal block at 0x00561378, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {72} normal block at 0x005617F8, 48 bytes long.
Data: < x > E4 B8 07 78 0F 00 00 00 0F 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {71} normal block at 0x005617A0, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {70} normal block at 0x00561748, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {69} normal block at 0x005616D0, 54 bytes long.
Data: < x > E4 B8 07 78 12 00 00 00 12 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {68} normal block at 0x00561670, 34 bytes long.
Data: < x > E4 B8 07 78 08 00 00 00 08 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {67} normal block at 0x00561618, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {66} normal block at 0x005615B8, 36 bytes long.
Data: < x > E4 B8 07 78 09 00 00 00 09 00 00 00 01 00 00 00
Object dump complete.
Is there another way I can double check the memory leaks don't exist? I installed deleaker as well but it is buggy program, it holds on pdb files and was not releasing it...that caused me more pain.
According to the following MSKB article, this is probably expected:
Memory leaks are reported when you use multiple MFC DLLs
Quoting from the linked page:
These memory leaks are reported when multiple versions of the MFC DLL
are loaded in the same process. Since MFC extension (AFXDLL) DLLs
require the exact same MFC DLL as the call application, this problem
can only occur when using MFC regular (USRDLL) DLLs or ActiveX
Controls (OCX) that use the shared version of MFC.
The most common case is mixing ANSI (MFC4xd.DLL) and UNICODE
(MFC4xxUd.DLL) versions of MFC in the same process. This can also
occur when mixing MFC42d.DLL and MFC40d.DLL.
And as far as resolving the "problem" goes:
These memory leak notifications are false, and can be ignored. Since
neither copy of MFC knows about the other ones, it's not easy to stop
these false leaks from being reported.

What is the ds:0023:003a3000=?? stuff on the end of a drwatson FAULT?

I have the following entry in a Dr Watson log. What is the significance of the "ds:0023:003a3000=??" part of the entry to the right of the FAULT line?
*----> State Dump for Thread Id 0xdfc <----*
eax=00000000 ebx=00390320 ecx=0854ff48 edx=09e44bfc esi=00012ce1 edi=0854ff61
eip=00465c51 esp=0854ff30 ebp=00000000 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
function: sysman
00465c37 49 dec ecx
00465c38 eb02 jmp sysman+0x65c3c (00465c3c)
00465c3a 33c9 xor ecx,ecx
00465c3c 8d542428 lea edx,[esp+0x28]
00465c40 52 push edx
00465c41 51 push ecx
00465c42 8d4c2418 lea ecx,[esp+0x18]
00465c46 e8d5c0fcff call sysman+0x31d20 (00431d20)
00465c4b 33c0 xor eax,eax
00465c4d 8d4c2418 lea ecx,[esp+0x18]
FAULT ->00465c51 8a441eff mov al,[esi+ebx-0x1] ds:0023:003a3000=??
00465c55 50 push eax
00465c56 6864074900 push 0x490764
00465c5b 51 push ecx
00465c5c e8cfd0fcff call sysman+0x32d30 (00432d30)
00465c61 8d542424 lea edx,[esp+0x24]
00465c65 68689f4800 push 0x489f68
00465c6a 8d44242c lea eax,[esp+0x2c]
00465c6e 52 push edx
00465c6f 50 push eax
00465c70 e83bc3fcff call sysman+0x31fb0 (00431fb0)
*----> Stack Back Trace <----*
ChildEBP RetAddr Args to Child
00000000 00000000 00000000 00000000 00000000 sysman+0x65c51
*----> Raw Stack Dump <----*
000000000854ff30 58 01 55 08 75 07 c8 09 - 00 00 00 00 18 6d c7 01 X.U.u........m..
000000000854ff40 fc 4b e4 09 04 bd 47 00 - 04 bd 47 00 fc 0c c9 01 .K....G...G.....
000000000854ff50 ac ca ae 09 64 5f c4 01 - 20 37 37 30 32 34 3a 20 ....d_.. 77024:
000000000854ff60 00 b3 42 00 a8 ff 54 08 - 90 a6 47 00 02 00 00 00 ..B...T...G.....
000000000854ff70 8b c5 42 00 b8 ff 54 08 - 2e 03 39 00 28 99 cb 01 ..B...T...9.(...
000000000854ff80 ff ff ff ff 00 00 00 00 - 00 00 00 00 20 1e cb 01 ............ ...
000000000854ff90 a6 f7 ba 77 06 00 00 00 - c9 f7 ba 77 e1 6b d9 09 ...w.......w.k..
000000000854ffa0 06 00 00 00 1f 00 00 00 - 68 00 55 08 c1 a0 47 00 ........h.U...G.
000000000854ffb0 00 00 00 00 58 c4 42 00 - c9 a5 ca 09 d1 fb 38 0a ....X.B.......8.
000000000854ffc0 27 00 00 00 e1 6b d9 09 - ef f2 41 00 c9 a5 ca 09 '....k....A.....
000000000854ffd0 01 59 cc 01 38 00 55 08 - ec 00 55 08 00 00 00 00 .Y..8.U...U.....
000000000854ffe0 e0 00 55 08 ff ff ff ff - 89 00 00 00 01 00 01 01 ..U.............
000000000854fff0 c8 ff 54 08 b8 ff 54 08 - 77 00 55 08 29 a5 ca 09 ..T...T.w.U.)...
0000000008550000 51 00 00 00 5f 00 00 00 - 00 9f 82 7c 61 36 ca 01 Q..._......|a6..
0000000008550010 25 00 00 00 3f 00 00 00 - 00 ce bb 77 91 b7 c7 01 %...?......w....
0000000008550020 19 00 00 00 1f 00 00 00 - 00 ff ff ff d9 28 cc 01 .............(..
0000000008550030 0b 00 00 00 1f 00 00 00 - 00 00 55 08 d1 fb 38 0a ..........U...8.
0000000008550040 27 00 00 00 3f 00 00 00 - 00 20 ba 77 00 00 00 00 '...?.... .w....
0000000008550050 00 00 00 00 00 00 00 00 - 20 b7 c7 01 00 00 00 00 ........ .......
0000000008550060 00 00 00 00 00 00 00 00 - b4 00 55 08 1b 90 47 00 ..........U...G.`
To summarize:
You get a register dump here:
eax=00000000 ebx=00390320 ecx=0854ff48 edx=09e44bfc esi=00012ce1 edi=0854ff61
eip=00465c51 esp=0854ff30 ebp=00000000 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
The eip indicates the instruction that failed:
FAULT ->00465c51 8a441eff mov al,[esi+ebx-0x1] ds:0023:003a3000=??
The stuff at the end is the address that failed to read, which is the "usual" data segment of 23, and address 3A3000, whcih is composed of esi and ebx minus 1: 390320+12ce1-1. To me, that looks like an index gone bad - 3a3000 would be the first address of a new "page" in memory, so that's why it's failing at that point. 77025 bytes into an array is quite a long way, but it is of course possible that it's something else that is wrong.