64bit sys BSOD check plz.

c++ / delphi package - dll injection and api hooking

64bit sys BSOD check plz.

Postby kimjw0820 » Mon Jul 24, 2017 7:31 am

hello madshi,

sorry minidump...

version : madCodeHook 3.1.16
module name : jshkdrv.sys == renameme64.sys

Can you check?
thanks.

Code: Select all
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7F, {8, fffff80197151e70, ffffb200b2e4ffd0, fffff80198053d40}

*** WARNING: Unable to verify timestamp for jshkdrv.sys
*** ERROR: Module load completed but symbols could not be loaded for jshkdrv.sys
Probably caused by : memory_corruption

Followup:     memory_corruption
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: fffff80197151e70
Arg3: ffffb200b2e4ffd0
Arg4: fffff80198053d40

Debugging Details:
------------------


DUMP_CLASS: 1

DUMP_QUALIFIER: 400

BUILD_VERSION_STRING:  15063.0.amd64fre.rs2_release.170317-1834

SYSTEM_MANUFACTURER:  Hewlett-Packard

SYSTEM_PRODUCT_NAME:  HP ProDesk 400 G2 MT

SYSTEM_SKU:  G3V26AV

BIOS_VENDOR:  Hewlett-Packard

BIOS_VERSION:  L02 v02.36

BIOS_DATE:  11/05/2014

BASEBOARD_MANUFACTURER:  Hewlett-Packard

BASEBOARD_PRODUCT:  198E

DUMP_TYPE:  2

BUGCHECK_P1: 8

BUGCHECK_P2: fffff80197151e70

BUGCHECK_P3: ffffb200b2e4ffd0

BUGCHECK_P4: fffff80198053d40

BUGCHECK_STR:  0x7f_8

TRAP_FRAME:  fffff80197151e70 -- (.trap 0xfffff80197151e70)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=ffffc784800373a0
rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80198053d40 rsp=ffffb200b2e4ffd0 rbp=ffffb200b2e50039
 r8=ffffb200b2e50038  r9=0000000000000000 r10=00007ffffffeffff
r11=fffff801981919a3 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!KiAbProcessContextSwitch+0x120:
fffff801`98053d40 e8ab160000      call    nt!KiAbEntryGetLockedHeadEntry (fffff801`980553f0)
Resetting default scope

CPU_COUNT: 4

CPU_MHZ: cdc

CPU_VENDOR:  GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3c

CPU_STEPPING: 3

CPU_MICROCODE: 6,3c,3,0 (F,M,S,R)  SIG: 1E'00000000 (cache) 1E'00000000 (init)

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  CODE_CORRUPTION

PROCESS_NAME:  conhost.exe

CURRENT_IRQL:  2

ANALYSIS_SESSION_HOST:  DESKTOP-3DKN04D

ANALYSIS_SESSION_TIME:  07-24-2017 16:22:48.0454

ANALYSIS_VERSION: 10.0.14321.1024 amd64fre

EXCEPTION_RECORD:  ffffb200b2e519d0 -- (.exr 0xffffb200b2e519d0)
ExceptionAddress: 00007ff5e1647000
   ExceptionCode: 00000002
  ExceptionFlags: 00000000
NumberParameters: -136
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000000
   Parameter[2]: 0000000000000000
   Parameter[3]: 0000000000000000
   Parameter[4]: 0000000000000000
   Parameter[5]: 0000000000000000
   Parameter[6]: 0000000000000000
   Parameter[7]: 0000000000000000
   Parameter[8]: 0000000000000000
   Parameter[9]: 0000000000000000
   Parameter[10]: 0000000000000000
   Parameter[11]: 0000000000000000
   Parameter[12]: 0000000000000000
   Parameter[13]: fffff80198194e57
   Parameter[14]: 0000000000000000

STACK_OVERFLOW: Stack Limit: ffffb200b2e50000. Use (kF) and (!stackusage) to investigate stack usage.

LAST_CONTROL_TRANSFER:  from fffff801981968a9 to fffff8019818b4c0

STACK_TEXT: 
fffff801`97151d28 fffff801`981968a9 : 00000000`0000007f 00000000`00000008 fffff801`97151e70 ffffb200`b2e4ffd0 : nt!KeBugCheckEx
fffff801`97151d30 fffff801`981946f3 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff801`97151e70 fffff801`98053d40 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb3
ffffb200`b2e4ffd0 fffff801`981904a5 : 005c0073`00650063 005c0070`00000000 006f0073`00000000 00650063`00000000 : nt!KiAbProcessContextSwitch+0x120
ffffb200`b2e500a0 fffff801`9818ec9a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxDispatchInterrupt+0xb5
ffffb200`b2e501e0 fffff801`9804b42d : ffffb200`b2e56000 ffffb200`b2e50470 ffffb200`b2e50bd0 00000000`00000000 : nt!KiDpcInterrupt+0xca
ffffb200`b2e50370 fffff801`98175472 : fffff801`98325464 00000000`00000001 ffffb200`b2e51bf0 ffffb200`b2e56000 : nt!RtlUnwindEx+0x11d
ffffb200`b2e50a40 fffff801`9819199d : 00000000`00000000 ffffb200`b2e50be0 00000000`00000000 00000000`00000000 : nt!_C_specific_handler+0xe2
ffffb200`b2e50ab0 fffff801`9804ad94 : ffffb200`b2e51200 ffffb200`b2e50be0 00000000`00000000 00000000`00000000 : nt!RtlpExecuteHandlerForException+0xd
ffffb200`b2e50ae0 fffff801`98049b36 : ffffb200`b2e519b8 ffffb200`b2e51700 ffffb200`b2e519b8 ffffb200`b2e519b8 : nt!RtlDispatchException+0x404
ffffb200`b2e511d0 fffff801`9819698e : ffffb200`b2e519d0 00000000`00000000 ffffc784`80694580 00000000`00000000 : nt!KiDispatchException+0x1f6
ffffb200`b2e51880 fffff801`98194e57 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiExceptionDispatch+0xce
ffffb200`b2e51a60 fffff801`98127b42 : ffffffff`00000420 fffff801`9805f03e ffff98cc`662ffeb8 ffff98cc`663317f8 : nt!KiPageFault+0x217
ffffb200`b2e51bf0 fffff801`980db97c : ffff98bf`faf0b238 ffff98bf`00000018 ffffffff`ffffffff ffffc784`80694580 : nt!MiMakeProtoLeafValid+0x7a
ffffb200`b2e51c70 fffff801`984f6be9 : 00007ff5`e1647000 00000000`00000000 00000000`00000001 00000000`00000000 : nt!MiSplitPrivatePage+0x2fc
ffffb200`b2e51d30 fffff801`984f6a65 : 00007ff5`e1647000 ffffc784`79ec5e08 00000000`00000280 00007ff5`e1647000 : nt!MiCopyToCfgBitMap+0x129
ffffb200`b2e51e00 fffff801`984f6134 : ffffc784`80037400 fffff801`98082059 00007ff8`5d9ca000 fffff801`980782a9 : nt!MiPopulateCfgBitMap+0xb1
ffffb200`b2e51e90 fffff801`984ace45 : 00000000`00002000 fffff801`9807891b 00000000`0000a000 ffffc784`7dc59550 : nt!MiMarkPrivateOpenCfgBits+0x30
ffffb200`b2e51ed0 fffff801`984d6d81 : 00000000`00000002 ffffb200`b2e52280 00000000`00000000 00000000`00002000 : nt!MiCommitVadCfgBits+0x175
ffffb200`b2e51f10 fffff801`984d6390 : ffffc784`80037080 fffff801`984ab8c1 00000000`00000000 00000000`00000000 : nt!MiAllocateVirtualMemory+0x9e1
ffffb200`b2e52130 fffff801`98196413 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtAllocateVirtualMemory+0x40
ffffb200`b2e52190 fffff801`9818e6a0 : fffff800`908c7b76 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
ffffb200`b2e52398 fffff800`908c7b76 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiServiceLinkage
ffffb200`b2e523a0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00002000 : jshkdrv+0x7b76


STACK_COMMAND:  kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
    fffff8019805f052 - nt!MiIsAddressValid+c2
   [ f6:98 ]
    fffff8019805f0e4 - nt!MmUnmapLockedPages+74 (+0x92)
   [ f6:98 ]
    fffff801980b0b54 - nt!MiGetPage+a4 (+0x51a70)
   [ fa:fb ]
    fffff801980b1558 - nt!MiCompletePrivateZeroFault+518 (+0xa04)
   [ f6:98 ]
    fffff801980b1568 - nt!MiCompletePrivateZeroFault+528 (+0x10)
   [ fa:fb ]
    fffff80198127b16 - nt!MiMakeProtoLeafValid+4e (+0x765ae)
   [ f6:98 ]
    fffff8019829f384-fffff8019829f385  2 bytes - nt!ExFreePoolWithTag+364
   [ fb f6:cc 98 ]
8 errors : !nt (fffff8019805f052-fffff8019829f385)

MODULE_NAME: memory_corruption

IMAGE_NAME:  memory_corruption

FOLLOWUP_NAME:  memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP:  0

MEMORY_CORRUPTOR:  LARGE

FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_LARGE

BUCKET_ID:  MEMORY_CORRUPTION_LARGE

PRIMARY_PROBLEM_CLASS:  MEMORY_CORRUPTION_LARGE

TARGET_TIME:  2017-07-24T07:12:03.000Z

OSBUILD:  15063

OSSERVICEPACK:  483

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK:  272

PRODUCT_TYPE:  1

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS

OS_LOCALE: 

USER_LCID:  0

OSBUILD_TIMESTAMP:  2017-07-07 15:06:35

BUILDDATESTAMP_STR:  170317-1834

BUILDLAB_STR:  rs2_release

BUILDOSVER_STR:  10.0.15063.0.amd64fre.rs2_release.170317-1834

ANALYSIS_SESSION_ELAPSED_TIME: 19a4

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:memory_corruption_large

FAILURE_ID_HASH:  {e29154ac-69a4-0eb8-172a-a860f73c0a3c}

Followup:     memory_corruption
Attachments
072417-5968-01.zip
(139.89 KiB) Downloaded 8 times
kimjw0820
 
Posts: 20
Joined: Fri Sep 11, 2015 1:54 am

Re: 64bit sys BSOD check plz.

Postby madshi » Mon Jul 24, 2017 9:14 am

Two questions:

1) Can you reproduce this? Or was this a one-time-only BSOD?
2) Do you know if this problem was introduced by 3.16? Or might it also have been in older versions, already?

I've had another customer report such a problem in NtAllocateVirtualMemory, too, but so far he's been unable to reproduce it in any reliable way, so it's very hard to track it down. For some reason it seems that calling the OS NtAllocateVirtualMemory API sometimes crashes, and I don't know why. In 3.16 I've even added a try..except block around the NtAllocateVirtualMemory call, just to be safe, but it doesn't seem to help much. If you have a way to reliably reproduce this, that would be a great help to finding a cure for this BSOD.
madshi
Site Admin
 
Posts: 9340
Joined: Sun Mar 21, 2004 5:25 pm

Re: 64bit sys BSOD check plz.

Postby kimjw0820 » Mon Jul 24, 2017 11:18 am

thank you!
this BSOD one-time-only...
I took that action. C:\Windows\System32\drivers\ sys to change file name.
and consent.exe popup.
BSOD occurred when the ok button was pressed.

my system : windows 10 pro 1703 64bit.
kimjw0820
 
Posts: 20
Joined: Fri Sep 11, 2015 1:54 am

Re: 64bit sys BSOD check plz.

Postby madshi » Mon Jul 24, 2017 11:27 am

Well, the BSOD says "memory corruption". That seems to be the sort of bug that could have a cause somewhere else than in the crash location. E.g. it's possible that some other driver produced memory corruption and the OS just noticed when madCodeHook's driver tried to allocate something.

But of course I would say that because it would mean it's not my fault... :wink: So take this with a pinch of salt.

If you can find any way to reproduce this problem, please let me know. Until then I don't really know what to do. If an OS API crashes when I call it, then the only way it could be my fault is if I used wrong parameters. But if I used wrong parameters, shouldn't it crash all the time? So right now I'd like to think that it might not be my fault. But it's hard to be sure.
madshi
Site Admin
 
Posts: 9340
Joined: Sun Mar 21, 2004 5:25 pm

Re: 64bit sys BSOD check plz.

Postby kimjw0820 » Mon Jul 24, 2017 11:29 am

ok! Thank you for your check.
kimjw0820
 
Posts: 20
Joined: Fri Sep 11, 2015 1:54 am

Re: 64bit sys BSOD check plz.

Postby iconic » Tue Jul 25, 2017 11:38 am

When a process image is first mapped (.exe), followed by ntdll it's safe to allocate within this window of time from inside an image load callback. If you wait longer than this (say when kernel32.dll is mapped) the address space is locked during image load callbacks and perhaps others so allocating after this from within one can cause deadlocks and unpredictable behavior (including BSODs). All depends on when you're allocating and whether you're doing this in or out of context. In order to prevent issues you need to ensure that you're calling ZwAllocateVirtualMemory() at PASSIVE_LEVEL, if a callback enters APC_LEVEL it can cause the undesirable

--Iconic
iconic
 
Posts: 802
Joined: Wed Jun 08, 2005 5:08 am

Re: 64bit sys BSOD check plz.

Postby madshi » Thu Jul 27, 2017 8:10 am

According to a crash dump sent to me by kimjw0820 the crash occurred when calling NtAllocateVirtualMemory inside of a PsSetCreateProcessNotifyRoutine handler. The MS documentation says those handlers are called at PASSIVE_LEVEL, so I'm totally not sure why the crash happens. The only thing I've changed recently is that I'm now allocating 2 memory pages instead of 1 page. And that seems to be enough to cause issues (but only very rarely) when it worked fine before.

:cry:

@kimjw0820, you can't reproduce the issue in any way, or can you? I'm asking because in your email you wrote that this issue didn't occur in driver 3.1.14. But if you can't reproduce the issue, then how can you know that it didn't occur in 3.1.14, but now occurs in 3.1.16? If you *can* reproduce the issue with 3.1.16, then maybe I could create some test versions to try to find a workaround or something...
madshi
Site Admin
 
Posts: 9340
Joined: Sun Mar 21, 2004 5:25 pm

Re: 64bit sys BSOD check plz.

Postby iconic » Fri Jul 28, 2017 10:18 am

@Mathias,

Ahh ok, I was specifically speaking of image load notifications. CreateProcess notify routines should always be PASSIVE_LEVEL indeed. However, since this callback executes so early in the process life a lot of things aren't even fully initialized yet (i.e> PEB access to the process filename and cmdline buffers are relative offsets to the structure describing them and not yet their own virtual addresses) - it's why flags such as RTL_USER_PROCESS_PARAMETERS_NORMALIZED exist, to check for this type of thing (uninitialized data) ;) I'd be weary of allocating any VM at this stage, especially with MEM_COMMIT, however as you know it can be done. Likely the double alloc is causing issues. What are the sizes and alloc types?

--Iconic
iconic
 
Posts: 802
Joined: Wed Jun 08, 2005 5:08 am

Re: 64bit sys BSOD check plz.

Postby madshi » Fri Jul 28, 2017 10:29 am

Well, I've always been allocating memory in CreateProcess notify, and it used to work fine. The size is 2 * 4096 (two memory pages). It used to be less than 1 memory page in older versions. I'm first using "MEM_RESERVE" and "PAGE_EXECUTE_READWRITE", so that I'm able to allocate at a specific address, and afterwards I'm doing "MEM_COMMIT" and "PAGE_EXECUTE_READWRITE". Well, that's the v3 driver. In v4 I'm using "PAGE_READWRITE" instead of "PAGE_EXECUTE_READWRITE".

I had tried to move the allocation and injection to the ImageLoad notify routine in the v4 driver, but I had to undo that change because in Windows 7 x64 it caused VirtualBox to no longer be able to start its VMs. In Windows 2003 x64 it was even worse than that. Once I moved allocation and injection back to CreateProcess notify, 2003 and 7 were happy again.
madshi
Site Admin
 
Posts: 9340
Joined: Sun Mar 21, 2004 5:25 pm

Re: 64bit sys BSOD check plz.

Postby iconic » Sat Jul 29, 2017 6:48 am

Are you able to reserve and commit in a single call, perhaps double to 2 PAGE_SIZEs in a single call or would that break your logic (maybe you don't want pages to share boundaries in this case)?

Code: Select all
        dwSize = 4096 * 2;
        Status = ZwAllocateVirtualMemory(hProcess,
                                         &BaseAddress,
                                         0,
                                         &dwSize,
                                         MEM_RESERVE | MEM_COMMIT,
                                         PAGE_EXECUTE_READWRITE);


I had tried to move the allocation and injection to the ImageLoad notify routine in the v4 driver, but I had to undo that change because in Windows 7 x64 it caused VirtualBox to no longer be able to start its VMs.


Hmmm weird. I've always used an image load notification for kernel mode injection and I suppose I've been fortunate because I've never encountered any issues at all. Just depends on what you're doing and how you're doing it I suppose.

--Iconic
iconic
 
Posts: 802
Joined: Wed Jun 08, 2005 5:08 am

Re: 64bit sys BSOD check plz.

Postby madshi » Sat Jul 29, 2017 6:27 pm

I've already doing one call with dwSize = 4096 * 2. I've actually thought of maybe splitting it into 2 calls with 4096 bytes each. However, that would require me to dynamically change my code injection stub. It's easier to have both pages right next to each other.

Allocating in image load worked fine for me in most cases, but there were a few fringe cases. I'm not sure if your solution would have the same problem. Maybe it depends on some factors whether it's a problem or not to allocate there.
madshi
Site Admin
 
Posts: 9340
Joined: Sun Mar 21, 2004 5:25 pm

Re: 64bit sys BSOD check plz.

Postby iconic » Sat Jul 29, 2017 10:32 pm

Well, my "allocation" occurs in a special kernel mode APC which in-turn queues a usermode APC. It's actually not allocating directly within the image load callback at all. Allocating any memory, as I've mentioned a few posts ago, can create issues if the callback is at APC_LEVEL, only at PASSIVE_LEVEL can it be done safely and that is only usually the first 2 images (main .exe and NTDLL). I run Virtual Box and many other VM software applications and haven't had a problem. But, I also don't use Zw/NtAllocateVirtualMemory at all, I use a read-only mapped section for this in which I charge against the pagefile per process. When all DLLs are actually done calling LoadLibraryExW (3 params fit fine within parameter confines of APC APIs, so I don't need a stub for 4 with LdrLoadDll) by referencing the section the last queued APC is always to deallocate the section memory that was mapped previously. Since APCs execute synchronously per thread and in FIFO order this works the way I expect it to and has for nearly 10 years now without any memory leaks. Another advantage of image load notifications is that you can wait until kernel32.dll is loaded, this will automatically weed out native processes such as SMSS which never load kernel32.dll anyhow. Simply don't inject until you receive this condition which also tells you that it's a new process spawning

--Iconic
iconic
 
Posts: 802
Joined: Wed Jun 08, 2005 5:08 am

Re: 64bit sys BSOD check plz.

Postby madshi » Sun Jul 30, 2017 8:34 am

Yeah, must be the kernel mode APC "event" which allows you to allocate safely. Unfortunately I've had problems with my APC injection solution. The wow64 problems might be solvable, but I also had problems in straight native 64bit, when the hook dll's stack reserve/commit PE fields were too large. This only made problems with APC injection but not with my current injection method.

Anyway, my plan is to add the hook dll to the import data directory in a future version. Obviously I'll still need to allocate memory for that, though.

The big thing I don't understand is why the new driver now sometimes has allocation problems while I've never had any such trouble in the past. But the problem is very very rare so nobody seems to be able to reliably reproduce it. Which makes it very hard to analyze the problem. Maybe I should try using mapped sections instead of NtAllocateVirtualMemory. Do mapped sections still work even if the process is "locked" for allocations?
madshi
Site Admin
 
Posts: 9340
Joined: Sun Mar 21, 2004 5:25 pm

Re: 64bit sys BSOD check plz.

Postby iconic » Mon Jul 31, 2017 5:31 pm

I also had problems in straight native 64bit, when the hook dll's stack reserve/commit PE fields were too large. This only made problems with APC injection but not with my current injection method.


A DLL's Stack Reserve/Commit fields should be ignored by the OS, only the main process module's PE fields matter since its the housing for all loaded DLLs. You can run the following test code in a DLL and then call it from a EXE - the EXE will fail to display the messagebox while the DLL will succeed proving these fields inside a DLL aren't relevant at all.

Code: Select all
procedure ThreadProc(pArg: Pointer); stdcall;
begin
    MessageBox(0, 'Hello', 'Test', MB_OK);
    ExitThread(0);
end;


procedure TestStackFields();
var
      oldProt: DWORD;
      nt: PImageNtHeaders;
      dwThreadId: DWORD;
      hThread: THandle;
      SysInf: SYSTEM_INFO;
begin
      GetSystemInfo(SysInf);
      if VirtualProtect(Pointer(hInstance), SysInf.dwPageSize, PAGE_READWRITE, @oldProt) then
      begin
      nt := Pointer(hInstance + DWORD(PImageDosHeader(hInstance)._lfanew));
      nt.OptionalHeader.SizeOfStackReserve := $DEADC0DE;
      VirtualProtect(Pointer(hInstance), SysInf.dwPageSize, oldProt, @oldProt);
      hThread := CreateThread(nil, 0, @ThreadProc, nil, 0, dwThreadId);
      if hThread <> 0 then
      CloseHandle(hThread);
      end;
end;



Anyway, my plan is to add the hook dll to the import data directory in a future version. Obviously I'll still need to allocate memory for that, though.


Microsoft Detours does this. I mentioned this in our emails some time ago. It's a good method and of course allows you to load before statically linked modules so you don't miss their API calls in the case of hooking API. It's relatively easy to do, too.

The big thing I don't understand is why the new driver now sometimes has allocation problems while I've never had any such trouble in the past


Yes that is very strange as you stated. The problem with it happening so uncommonly is a problem in itself. Maybe encourage a few testers to enable Driver Verifier on their injection drivers to see what turns up, it should provide better information to assist you when a bugcheck is raised. Also, a full dump would be better than a mini-dump in your case.


Do mapped sections still work even if the process is "locked" for allocations?


The lock only happens when you're in some callbacks, such as a load image notification routine. EPROCESS->AddressCreationLock is a mutex and it's held until the callback completes. Allocating memory or even querying memory during this time can create issues, the main one being a deadlock. In your case however I don't think this is the problem since you've mentioned doing the allocation at PASSIVE_LEVEL always and inside a process creation callback instead of load image. The problem might have more to do with the fact that you're allocating at an already existing virtual address and things get wonky somewhere in the region's range. In my lib I allocate (Section Map) just once per process however I also do so using MEM_TOP_DOWN (at the highest available virtual address at the time of invocation). I've witnessed allocations flat out fail randomly if I didn't specify this flag when a process is still uninitialized.

--Iconic
iconic
 
Posts: 802
Joined: Wed Jun 08, 2005 5:08 am


Return to madCodeHook

Who is online

Users browsing this forum: No registered users and 3 guests