C / C++ / MFC

Re: mfc LoadBitmap hangs my application...

16-Apr-20 16:37

I agree LoadBitmap should not fail like that but it is specified the resources are never lifted into RAM. They are tagged in special sections in the file and are excluded from the normal executable load to avoid using memory when not required. Remember a file may contain many resources for different resolutions, languages and the like and much would then be redundant duplicates hogging memory.

In vino veritas

charlieg17-Apr-20 9:43

charlieg

17-Apr-20 9:43

Windows CBT Hooks

Richard Andrew x6414-Apr-20 11:58

14-Apr-20 11:58

After I install a CBT global hook, does the application that called SetWindowsHookEx[^] need to stay alive for the hook to work for the lifetime of the user session?

Or may the application that installed the hook exit, thus leaving the hook DLL to operate by itself?

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

Richard MacCutchan14-Apr-20 21:21

14-Apr-20 21:21

The remarks section certainly implies quite strongly that the application that calls SetWindowsHookEx must keep running (and pumping messages).

Richard Andrew x6415-Apr-20 4:28

15-Apr-20 4:28

Thank you Richard. I reread the remarks and I see that you are correct.

Quote:
However, because a 32-bit application must run the hook code, the system executes the hook in the hooking app's context; specifically, on the thread that called SetWindowsHookEx. This means that the hooking application must continue to pump messages or it might block the normal functioning of the 64-bit processes.

When I install the hook, I must pass a pointer to the hook callback function. However, that's a pointer that's only valid inside the process space of the application installing the hook. How does it use that pointer to call the correct code inside the address space of the application that is a target of the hook? Confused | :confused:

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

Richard MacCutchan15-Apr-20 4:57

15-Apr-20 4:57

Richard Andrew x64 wrote:
a pointer to the hook callback function.

The system keeps that address (which is the target of the hook) and uses it to call back into your application at the appropriate time (i.e when the relevant hook event triggers). But if you close your application, its address space is destroyed and the hook is no longer valid, so the system will no longer call it.

Richard Andrew x6415-Apr-20 5:49

15-Apr-20 5:49

Thank you for your response.

OK, so if the system calls back into my application at the appropriate time, why must the system load the DLL containing the filter function into each process that is hooked?

IOW, if the hook function is run inside the installing application, why must the hook function DLL be injected into every targeted application?

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

Richard MacCutchan15-Apr-20 6:05

15-Apr-20 6:05

Sorry I don't know the answer to that one. There is an implication that injecting the hook into another process can be done of the call-back function is in a dll. If that is the case then the dll must be associated withe the address space of that process. I must admit it is a long time since I used this feature so my recollection of it is not 100%.

Richard Andrew x6415-Apr-20 8:01

15-Apr-20 8:01

OK Thank you for your contributions thus far.

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

leon de boer16-Apr-20 0:21

16-Apr-20 0:21

You need an instance handle to load the DLL ... guess what happens to the instance handle when the application terminates Smile | :)

In vino veritas

Richard Andrew x6416-Apr-20 2:53

16-Apr-20 2:53

Yes, thank you. I progressed to the point where I'm creating the hook and processing it successfully.

But now the problem is that when the hook installer application terminates, it crashes all of the hooked applications *even though* I call UnhookWindowsHookEx() to remove the hook before terminating.

Would you have any hints what I can do about that?

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

leon de boer16-Apr-20 4:02

16-Apr-20 4:02

The unhook is usually just done in WM_DESTROY of the main application.
From memory it must be before you post WM_QUIT which will kill the instance handle.

In vino veritas

Richard Andrew x6416-Apr-20 6:12

16-Apr-20 6:12

Do you mean that the system waits until the window receives the WM_DESTROY message before it actually unhooks the hook?

Or do you mean that I must call UnhookWindowsHookEx BEFORE the WM_QUIT message is posted?

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

leon de boer16-Apr-20 6:25

16-Apr-20 6:25

Unhook it before you post the WM_QUIT message

In vino veritas

Accessing HDD drive

_Flaviu14-Apr-20 9:32

14-Apr-20 9:32

How is the way to open a HDD drive with _open function in such a way to read even the boot section of this drive ? Here is the code:

int hd_h = _open(device, O_BINARY | O_RDWR | O_EXCL);

device is provided with

"\\\\?\\E:"

This is the code from ntfs library GitHub - vitalif/ntfs-3g: Fork of git://ntfs-3g.git.sourceforge.net/gitroot/ntfs-3g/ntfs-3g with FIEMAP support patch[^]

Why I am asking that ? Even if _open return 3, further more, the reading of boot section has failed.

Function

ntfs_boot_sector_is_ntfs

say that my boot device is not NTFS:

if (! ntfs_boot_sector_is_ntfs(bs))
{
    errno = EINVAL;
    goto error_exit;
}

BOOL ntfs_boot_sector_is_ntfs(NTFS_BOOT_SECTOR* b)
{
	u32 i;
	BOOL ret = FALSE;
	ntfs_log_debug("Beginning bootsector check.\n");

	ntfs_log_debug("Checking OEMid, NTFS signature.\n");
	if (b->oem_id != const_cpu_to_le64(0x202020205346544eULL))	// "NTFS    "
	{
		ntfs_log_error("NTFS signature is missing.\n");  // <--- my code run by here
		goto not_ntfs;
	}
....

Of course, this debugging session ran as admin mode.

Richard MacCutchan14-Apr-20 21:14

14-Apr-20 21:14

I not sure that you can access the boot sector using a drive letter. I think you need to address it as something like Device\Partition0. Google can probably find the correct syntax.

_Flaviu16-Apr-20 7:23

16-Apr-20 7:23

Good point, I have tried in this way:

"\\\\.\\PHYSICALDRIVE2"

... but with exactly the same result ... strange ...

Richard MacCutchan16-Apr-20 9:28

16-Apr-20 9:28

I think there is a page somewhere on MSDN that explains how to access low level disks.

kalberts16-Apr-20 10:57

kalberts

16-Apr-20 10:57

I haven't gotten around to check this out myself yet, but I am studying the "Windows Internals" book by Mark Russinovich (the guy creating the Sysinternals suite). There I found that the object name \Device\HarddiskX\DRX (with 'X' being replaced by a digit from 0 upwards; you can find it using the Sysinternals WinObj utility).

It is not clear to me when to use this name and when to use the \Global??\PhysicalDriveX name. Russinovich writes that "The Windows application layer converts the name to \Global??\PhysicalDriveX berofe handling the name to the Windwows object manager" - it seems like that PhysicalDriveX format is some old legacy format. It is far from clear to me!

So you may try a Global??\ prefix, or you might try \Device\HarddiskX\DRX (appearently with X replaced by 2 in your case). When you find out what works, tell it, and I will use it when I get that far myself!

JudyL_MD17-Apr-20 4:48

JudyL_MD

17-Apr-20 4:48

Given that you're looking at ntfs, can we assume you're doing this under Windows? According to
https://support.microsoft.com/en-us/help/100027/info-direct-drive-access-under-win32[^], you can't open the raw drive with exclusive access.

Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein

_Flaviu19-Apr-20 2:32

19-Apr-20 2:32

As that document say, I have tried "\\\\.\\PhysicalDrive2", with exactly the same result.

Richard MacCutchan19-Apr-20 3:01

19-Apr-20 3:01

Are you sure that is a valid disk name? If you enter the command Get-PhysicalDisk in a PowerShell window, you will get a list of the known physical disks on your system. See Get-PhysicalDisk[^].

[edit]
Here is a better command:

Get-WmiObject Win32_DiskDrive

[/edit]

Richard MacCutchan19-Apr-20 3:25

19-Apr-20 3:25

I just tried the following code and it returns a valid handle. Note that this must run with administrator privileges:

C++

HANDLE hFile = CreateFileW(L"\\\\.\\PhysicalDrive0",
    GENERIC_READ,
    FILE_SHARE_READ | FILE_SHARE_WRITE,
    NULL,
    OPEN_EXISTING,
    FILE_ATTRIBUTE_NORMAL,
    NULL
);
cout << "Handle: " << hex << hFile << endl;
CloseHandle(hFile);

_Flaviu19-Apr-20 8:48