- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Access violation reading location 0x00000510
We`ve got this big problem in our game.
Access violation happens only under Win7 + Intel graphics (GMA 3100, GMA 950) and works fine under WinXP or with non-Intel cards so it is definitely not a problem of our 3d engine. Affected both 8.15.10.1749 driver and the latest available 1930.
Call stack right after crash:
igdumd32.dll!01854ec5()
[Frames below may be incorrect and/or missing, no symbols loaded for igdumd32.dll]
igdumd32.dll!0186c20f()
igdumd32.dll!0189df4a()
igdumd32.dll!0189af4c()
igdumd32.dll!0189d2ea()
igdumd32.dll!018a0276()
igdumd32.dll!0196bd79()
igdumd32.dll!0187863a()
igdumd32.dll!01863b13()
d3d9.dll!CD3DDDIDX10::DrawIndexPrim() + 0x204 bytes
d3d9.dll!wmt_DRAW_CLIPPED_PRIM() + 0x1be bytes
d3d9.dll!wmt_PVFUNCS::ProcessIndexedPrimitive() + 0x11a bytes
d3d9.dll!CD3DDDIDX8::ProcessIndexedPrimitiveC() + 0x119 bytes
d3d9.dll!CD3DHal_DrawIndexedPrimitive() + 0xa4 bytes
d3d9.dll!CD3DBase::DrawIndexedPrimitive() + 0xc3 bytes
> lzView.exe!lzMesh::Dip(D3DXMATRIX * iTm=0x0abb9b18, int iFrame=0) Line 79 + 0x43 bytes C++
Help to find any workaround as soon as possible. Our customers have Intel graphics, so we need to fix this in some way.
I can make a bug repro, if it helps you dealing with this problem. Or if it is possible you may send to me igdumd32 pdb file, then I can provide more readable report.
Eugene.
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
does that provide any additional information via the debug runtime output? and/or a decorated call-stack?
what specifically is the app doing at that point? do all pointers point to valid data?
what is lzMesh?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've recompiled with D3D debugging on, but the crash is pretty far down in the igdumd32 driver. Here is a callstack (from the D3D level down):
igdumd32.dll!05b28d40()
[Frames below may be incorrect and/or missing, no symbols loaded for igdumd32.dll]
igdumd32.dll!05b6db5e()
igdumd32.dll!05b1f832()
igdumd32.dll!05b6dc4b()
igdumd32.dll!05b6de8b()
igdumd32.dll!05be8a52()
igdumd32.dll!05bc9a9d()
igdumd32.dll!05ba2668()
igdumd32.dll!05b7b714()
igdumd32.dll!05b7b952()
igdumd32.dll!05b31ac0()
igdumd32.dll!05a9c848()
igdumd32.dll!05a94dbf()
igdumd32.dll!05a92a5e()
igdumd32.dll!05a682ee()
igdumd32.dll!05a53991()
d3d9d.dll!CD3DDDIDX10_DrawPrimitive() + 0xb9 bytes
d3d9d.dll!CD3DBase::DrawPrimitive() + 0x395 bytes
d3d9d.dll!CDirect3DDevice9W::DrawPrimitive() + 0xd6 bytes
The crash occurs when the ECX register is dereferenced with a value of 0xABABABAB, which I assume is the fill value for the debug heap alloc.
The disassmbly code is:
05B28D30 push esi
05B28D31 push edi
05B28D32 mov edi,dword ptr [esp+0Ch]
05B28D36 mov esi,ecx
05B28D38 mov ecx,dword ptr [edi]
05B28D3A xor al,al
05B28D3C test ecx,ecx
05B28D3E je 05B28DA5
05B28D40 mov eax,dword ptr [ecx+10h] <- crash here
Registers are:
EAX = 00000000 EBX = 0018BAE8 ECX = 00000000 EDX = 00000000
ESI = 00000000 EDI = 00000000 EIP = 108F64E5 ESP = 0018B714
EBP = 0018B778 EFL = 00000000
The stack is:
0x0018B2E8 78 43 b9 15 d8 ed 78 05 5e db b6 05 1c b3 18 xC..x.^....
0x0018B2F7 00 d8 ed 78 05 54 b3 18 00 00 00 0c 00 00 00 .x.T.........
0x0018B306 00 00 48 21 9a 15 71 f0 04 00 00 00 00 00 32 ..H!.q......2
0x0018B315 f8 b1 05 30 b3 18 00 ab ab ab ab 00 00 00 00 .0.......
0x0018B324 d8 ed 78 05 68 b3 18 00 4b dc b6 05 01 00 00 x.h...K....
0x0018B333 00 00 00 00 00 00 00 00 00 94 b3 18 00 d8 ed ............
The draw call is for a 4 vertex D3DPT_TRIANGLEFAN
At the application level, everything looks good. Ie: the vertex data is valid. I'm not sure where the 0xABABABAB is coming from.
The crash is 100% repeatable (although the timing varies), but only for this card/driver combo at this point. Unfortunately we have a lot of users with that card/driver combo.. :/
Kevin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
http://blogs.msdn.com/b/jiangyue/archive/2010/03/16/windows-heap-overrun-monitoring.aspx
may be of some use.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's possible it's a heap overrun, of course.. But my gut is that that is unlikely, due to pretty long standing solid performance on other card/driver combos. I will explore this tomorrow or Thursday.
Is there anyway I could get a debug driver build to look at? It would make this a lot easier.
Thanks,
Kevin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't care if these chipsets are end of life. But even if they are, what about the HD 3000 chipset? Is that beyond it's support lifetime? https://www-ssl.intel.com/content/www/us/en/architecture-and-technology/hd-graphics/hd-graphics-developer.html?
Because your still advertising it like it's the bees knees, and even providing links to laptops that are selling it. Tribes Ascend, Mass Effect 3, and I'm sure other titles. All play perfectly well, up until some point where theres a particular type of effect and it variably decides to crash on it and the programfault is with igdumd32.dll usually because the file can't be found or something. Sounds like it's a problem with your drivers for Windows 7. So let these developers have whatever they're requesting so they can potentially fix their problems, and others will see how to fix it in their applications too.
Seriously I'm thinking about returning my laptop which is still within store warranty, just because of this very upsetting chipset that seemed to sound alright from all the reviews I had read.
Fix it Intel, lord knows I pay enough for your processors and chipsets, often times 15 - 35% more expensive than the alternative. People pay more for quality, if you can't provide that, then I'll purchase non-intel products - Namely AMD, Nvidia.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Similar issue on WIndows 8.1 with latest Intel video driver. Got access violations in Direct X DLLs when just trying to run old Diablo 1 game under Windows 8.1 on machine with HD 4000 graphics and 15.33.8.64.3345 driver. The driver is buggy. Previous version of the driver works with no issues.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Alexander S. wrote:
Similar issue on WIndows 8.1 with latest Intel video driver. Got access violations in Direct X DLLs when just trying to run old Diablo 1 game under Windows 8.1 on machine with HD 4000 graphics and 15.33.8.64.3345 driver. The driver is buggy. Previous version of the driver works with no issues.
Can you post the minidump file?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
iliyapolak wrote:
Can you post the minidump file?
Unfortunately I do not have the relevant minidump already, as I rolled back to old driver v.9.17.10.2875 and do not have the original error anymore.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Mr. Ganesh Kumar
I have a problem.
I am new at my company. I also asked my question from Microsoft, and they suggested to turn to the Intel driver developers with my question. I think you are one of the driver developer.
http://social.msdn.microsoft.com/Forums/en-US/611a579b-ee2d-4dc9-9bb4-cacf7df7f1b4/how-to-force-windows-ce-to-use-the-display-connected-to-the-hdmi-without-testing-the-hdmi?forum=winembplatdev
Our company develops hardvare devices, which run Windows 7 Embedded. (Not mobile, not Windows CE)
The hardware engineers made a small mistake in the HDMI hardware (they forgot to invert one line), and because of this, the HDMI socket wrongfuly detects the presence of the display. So, the Windows 7 Embedded senses that no display attached to the HDMI socket, but in fact, there is a display, just the Windows 7 Embedded beleives it wrongfuly.
And, after we can make the Windows beleive that it has a display, it handles the display correctly, so the only problem is the detection of the presence of the HDMI display.
We can suppose, that there is always a display on the HDMI, so we no need any kind of HDMI detection.
Our company sold 600 devices when they realize the hardware problem. (The display works fine after switching on the system, it becomes wrong after the first unplug -> plug OR first sleep -> wake up) So, the company sold 600 devices, and we cannot call them back, it would be too high cost, and loosing the trust.
We would like to change (update) the software, and we would like the new software to avoid any kind of HDMI line checking, any HDMI presence checking.
Can we somehow overrule the HDMI detection, and explain to the Windows 7 Embedded that it does have HDMI display even if it cannot sense the presence? Can we force the Windows 7 Embedded to use an HDMI display which it cannot sense?
The display chipset (and this handles the HDMI socket too) is Intel Graphics Media Accelerator 3600 Series
Driver provider: Intel Corporation
Driver Date: 15.03.2013
Driver Version: 8.14.8.1091
We also tried to modify the registry entries, we did not have full success.
We found this:
; OPTIONS FOR HOTPLUG THROUGH INF
;2 - Apply selected logic selected in VBT
;0 - Disable Hot Plug
;1 - Enable Hot Plug
;NOTE: Enable "INF_VBT_Override_EnableFeature" flag to use below given INF entries
So, we modified the registry entry INF_VBT_Override_EnableFeature to 1 (it was 0 before)
We also modified HotPlug_DVO_SDVO and HotPlug_CRT, we modified them to 0, both of them was 2.
... But no real success....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried to look into the igddim32.sys. I tried to figure out, why I cannot disable the HotPlug, so, if the driver really reads the HotPlug_DVO_SDVO, HotPlug_CRT and INF_VBT_Override_EnableFeature registry entries. I found these things:
10047D90 55 PUSH EBP 10047D91 8BEC MOV EBP,ESP 10047D93 83EC 10 SUB ESP,10 10047D96 E8 F5670100 CALL igddim32.1005E590 10047D9B 8945 F4 MOV DWORD PTR SS:[EBP-C],EAX 10047D9E C745 FC 00000000 MOV DWORD PTR SS:[EBP-4],0 10047DA5 C645 FB 00 MOV BYTE PTR SS:[EBP-5],0 10047DA9 C645 F3 00 MOV BYTE PTR SS:[EBP-D],0 10047DAD 837D F4 00 CMP DWORD PTR SS:[EBP-C],0 10047DB1 74 29 JE SHORT igddim32.10047DDC 10047DB3 8D45 FC LEA EAX,DWORD PTR SS:[EBP-4] 10047DB6 50 PUSH EAX 10047DB7 6A 04 PUSH 4 10047DB9 68 0CC51210 PUSH igddim32.1012C50C ; UNICODE "INF_VBT_Override_EnableFeature" 10047DBE 8B4D F4 MOV ECX,DWORD PTR SS:[EBP-C] 10047DC1 51 PUSH ECX 10047DC2 8B55 F4 MOV EDX,DWORD PTR SS:[EBP-C] 10047DC5 8B42 04 MOV EAX,DWORD PTR DS:[EDX+4] 10047DC8 FFD0 CALL EAX 10047DCA 0FB6C8 MOVZX ECX,AL 10047DCD 83F9 01 CMP ECX,1 10047DD0 75 0A JNZ SHORT igddim32.10047DDC 10047DD2 837D FC 00 CMP DWORD PTR SS:[EBP-4],0 10047DD6 76 04 JBE SHORT igddim32.10047DDC 10047DD8 C645 F3 01 MOV BYTE PTR SS:[EBP-D],1 10047DDC 0FB655 F3 MOVZX EDX,BYTE PTR SS:[EBP-D] 10047DE0 85D2 TEST EDX,EDX 10047DE2 0F84 4B020000 JE igddim32.10048033
... Lots of things ...
10047FA0 8D45 FC LEA EAX,DWORD PTR SS:[EBP-4] 10047FA3 50 PUSH EAX 10047FA4 6A 04 PUSH 4 10047FA6 68 10C71210 PUSH igddim32.1012C710 ; UNICODE "HotPlug_DVO_SDVO" 10047FAB 8B4D F4 MOV ECX,DWORD PTR SS:[EBP-C] 10047FAE 51 PUSH ECX 10047FAF 8B55 F4 MOV EDX,DWORD PTR SS:[EBP-C] 10047FB2 8B42 04 MOV EAX,DWORD PTR DS:[EDX+4] 10047FB5 FFD0 CALL EAX 10047FB7 0FB6C8 MOVZX ECX,AL 10047FBA 83F9 01 CMP ECX,1 10047FBD 75 26 JNZ SHORT igddim32.10047FE5 10047FBF 837D FC 02 CMP DWORD PTR SS:[EBP-4],2 10047FC3 73 20 JNB SHORT igddim32.10047FE5 10047FC5 8A55 FC MOV DL,BYTE PTR SS:[EBP-4] 10047FC8 80E2 01 AND DL,1 10047FCB C0E2 03 SHL DL,3 10047FCE 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8] 10047FD1 8A88 80000000 MOV CL,BYTE PTR DS:[EAX+80] 10047FD7 80E1 F7 AND CL,0F7 10047FDA 0ACA OR CL,DL 10047FDC 8B55 08 MOV EDX,DWORD PTR SS:[EBP+8] 10047FDF 888A 80000000 MOV BYTE PTR DS:[EDX+80],CL 10047FE5 8D45 FC LEA EAX,DWORD PTR SS:[EBP-4] 10047FE8 50 PUSH EAX 10047FE9 6A 04 PUSH 4 10047FEB 68 34C71210 PUSH igddim32.1012C734 ; UNICODE "HotPlug_CRT" 10047FF0 8B4D F4 MOV ECX,DWORD PTR SS:[EBP-C] 10047FF3 51 PUSH ECX 10047FF4 8B55 F4 MOV EDX,DWORD PTR SS:[EBP-C] 10047FF7 8B42 04 MOV EAX,DWORD PTR DS:[EDX+4] 10047FFA FFD0 CALL EAX 10047FFC 0FB6C8 MOVZX ECX,AL 10047FFF 83F9 01 CMP ECX,1 10048002 75 2F JNZ SHORT igddim32.10048033 10048004 837D FC 02 CMP DWORD PTR SS:[EBP-4],2 10048008 73 29 JNB SHORT igddim32.10048033 1004800A 66:0FB655 FC MOVZX DX,BYTE PTR SS:[EBP-4] 1004800F 66:83E2 01 AND DX,1 10048013 66:C1E2 0A SHL DX,0A 10048017 B8 FFFB0000 MOV EAX,0FBFF 1004801C 8B4D 08 MOV ECX,DWORD PTR SS:[EBP+8] 1004801F 66:2381 87000000 AND AX,WORD PTR DS:[ECX+87] 10048026 66:0BC2 OR AX,DX 10048029 8B55 08 MOV EDX,DWORD PTR SS:[EBP+8] 1004802C 66:8982 87000000 MOV WORD PTR DS:[EDX+87],AX 10048033 B0 01 MOV AL,1 10048035 8BE5 MOV ESP,EBP 10048037 5D POP EBP 10048038 C2 0400 RETN 4
I tried to make break point into this area, but OllyDbg never stopped. I would like to ask, if this area never executed, or, because this area executed at the initalisation of the Kernel Driver (igddim32.sys), and than the OllyDbg is not active yet?
I would like to ask an Intel Engineer to please respond to this entry.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>I tried to make break point into this area, but OllyDbg never stopped. I would like to ask, if this area never executed, or, because this area executed at the initalisation of the Kernel Driver (igddim32.sys), and than the OllyDbg is not active yet?>>>
I do not think if OllyDbg is a best tool for run-time kernel mode debugging of the driver.It simply cannot beat windows debugger in kernel mode debugging.I am sure that OllyDbg was not able to set a breakpoint because it is user mode debugger.
Now my suggestion is to connect two machines to each other and if both machines have Win 8 installed you can debug over Ethernet.At lest do the same experiment as it was done with OllyDbg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10047FA6 68 10C71210 PUSH igddim32.1012C710 ; UNICODE "HotPlug_DVO_SDVO" |
05 |
10047FAB 8B4D F4 MOV ECX,DWORD PTR SS:[EBP-C] |
06 |
10047FAE 51 PUSH ECX |
07 |
10047FAF 8B55 F4 MOV EDX,DWORD PTR SS:[EBP-C] |
08 |
10047FB2 8B42 04 MOV EAX,DWORD PTR DS:[EDX+4] |
09 |
10047FB5 FFD0 CALL EAX |
It seems that push igddim32.1012C710 instruction pushes onto the stack near pointer to aferomentioned structure, next local variable at [EBP-C] is saved on the stack the same variable is loaded into EDX register.Most interesting part is the indirect call through EAX register.Ad far I as was able to understand it could be variable which is located at [EBP-8] and could be a pointer to some function.Now with the help of windbg you would need to resolve that address.Probably AL contains the return value of the function called indirectly.Next those values are compared for equality and the transition is being made to code which pushes the pointer to "HotPlug_CRT" structure.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10047FA0 8D45 FC LEA EAX,DWORD PTR SS:[EBP-4] 10047FA3 50 PUSH EAX 10047FA4 6A 04 PUSH 4 10047FA6 68 10C71210 PUSH igddim32.1012C710 ; UNICODE "HotPlug_DVO_SDVO" 10047FAB 8B4D F4 MOV ECX,DWORD PTR SS:[EBP-C] 10047FAE 51 PUSH ECX 10047FAF 8B55 F4 MOV EDX,DWORD PTR SS:[EBP-C] 10047FB2 8B42 04 MOV EAX,DWORD PTR DS:[EDX+4] 10047FB5 FFD0 CALL EAX
This is only a registry query, (calling ntoskrnl.RtlQueryRegistryValues). It transfers all the necessary inputs, like handle for the opened key, etc.
10047FB7 0FB6C8 MOVZX ECX,AL 10047FBA 83F9 01 CMP ECX,1 10047FBD 75 26 JNZ SHORT igddim32.10047FE5
The return value arrives in AL, and this tests if the query was successfull or not. If AL=1 then the query was succesfull, otherwise it jumps out to 10047fe5. If the query was successfull, the code continues at the next instruction.
10047FBF 837D FC 02 CMP DWORD PTR SS:[EBP-4],2 10047FC3 73 20 JNB SHORT igddim32.10047FE5
This code executes only if the query was successfull, for example if the value exists in the registry tree. SS:[EBP-4] containst the value of "HotPlug_DVO_SDVO". If the value is greater or equialent with 2 than jumps out. Practically the value can be 0 or 1 to remain here. 0 means the HotPlug is enabled, 1 means HotPlug is disabled
10047FC5 8A55 FC MOV DL,BYTE PTR SS:[EBP-4] 10047FC8 80E2 01 AND DL,1 10047FCB C0E2 03 SHL DL,3
This is taking the result (which can be 0 or 1, so practicaly one bit, on the 0. position of the byte) and shifts to left by 3, so the bit will go to the 3. position of the byte. (can be 8 or 0)
10047FCE 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8] 10047FD1 8A88 80000000 MOV CL,BYTE PTR DS:[EAX+80] 10047FD7 80E1 F7 AND CL,0F7
This is taking the value of some local storage area, and "kills" the 3. bit of this local byte variable (because the new registry value will be stored at this freshly "killed" bit. (((SS:[EBP+8] is the addres of the local storage area, and DS:[EAX+80] is the local byte variable.)))
10047FDA 0ACA OR CL,DL
This is combining together the old data, which came from the local data area, and the new data which came from the registry, and it was shifted, and stored now in DL.
10047FDC 8B55 08 MOV EDX,DWORD PTR SS:[EBP+8] 10047FDF 888A 80000000 MOV BYTE PTR DS:[EDX+80],CL
And this is atoring back the combined data to the local data area.
So, practicly the code queried the registry value, and stored to one bit of a local byte variable of a local data area.
This is totaly clear for me.
But the problem this code, which I just discovered, and it seems, that this code is never called, so the stored bit will never be used any longer. The following whole procedure is ignored, never called, and this is the problem. I guess, that the driver was compiled with some conditional parameter, and the reference to (calling of) this procedure was not compiled to the code.
10046050 55 PUSH EBP 10046051 8BEC MOV EBP,ESP 10046053 83EC 0C SUB ESP,0C 10046056 C645 FF 00 MOV BYTE PTR SS:[EBP-1],0 1004605A E8 413F0000 CALL igddim32.10049FA0 1004605F 8945 F8 MOV DWORD PTR SS:[EBP-8],EAX 10046062 E8 B9170200 CALL igddim32.10067820 10046067 8945 F4 MOV DWORD PTR SS:[EBP-C],EAX 1004606A 837D 0C 00 CMP DWORD PTR SS:[EBP+C],0 1004606E 75 2E JNZ SHORT igddim32.1004609E 10046070 837D F4 00 CMP DWORD PTR SS:[EBP-C],0 10046074 74 11 JE SHORT igddim32.10046087 10046076 8B45 F4 MOV EAX,DWORD PTR SS:[EBP-C] 10046079 0FB648 1F MOVZX ECX,BYTE PTR DS:[EAX+1F] 1004607D 85C9 TEST ECX,ECX 1004607F 74 06 JE SHORT igddim32.10046087 10046081 C645 FF 00 MOV BYTE PTR SS:[EBP-1],0 10046085 EB 15 JMP SHORT igddim32.1004609C 10046087 8B55 08 MOV EDX,DWORD PTR SS:[EBP+8] 1004608A 66:8B82 87000000 MOV AX,WORD PTR DS:[EDX+87] 10046091 66:C1E8 0A SHR AX,0A 10046095 66:83E0 01 AND AX,1 10046099 8845 FF MOV BYTE PTR SS:[EBP-1],AL 1004609C EB 72 JMP SHORT igddim32.10046110 1004609E 837D 0C 02 CMP DWORD PTR SS:[EBP+C],2 100460A2 74 06 JE SHORT igddim32.100460AA 100460A4 837D 0C 03 CMP DWORD PTR SS:[EBP+C],3 100460A8 75 14 JNZ SHORT igddim32.100460BE 100460AA 8B4D 08 MOV ECX,DWORD PTR SS:[EBP+8] 100460AD 8A91 80000000 MOV DL,BYTE PTR DS:[ECX+80] 100460B3 C0EA 03 SHR DL,3 100460B6 80E2 01 AND DL,1 100460B9 8855 FF MOV BYTE PTR SS:[EBP-1],DL 100460BC EB 52 JMP SHORT igddim32.10046110 100460BE 837D 0C 06 CMP DWORD PTR SS:[EBP+C],6 100460C2 75 4C JNZ SHORT igddim32.10046110 100460C4 837D F4 00 CMP DWORD PTR SS:[EBP-C],0 100460C8 74 11 JE SHORT igddim32.100460DB 100460CA 8B45 F4 MOV EAX,DWORD PTR SS:[EBP-C] 100460CD 0FB648 20 MOVZX ECX,BYTE PTR DS:[EAX+20] 100460D1 85C9 TEST ECX,ECX 100460D3 74 06 JE SHORT igddim32.100460DB 100460D5 C645 FF 00 MOV BYTE PTR SS:[EBP-1],0 100460D9 EB 35 JMP SHORT igddim32.10046110 100460DB 8B55 F8 MOV EDX,DWORD PTR SS:[EBP-8] 100460DE 837A 10 04 CMP DWORD PTR DS:[EDX+10],4 100460E2 1BC0 SBB EAX,EAX 100460E4 83C0 01 ADD EAX,1 100460E7 74 27 JE SHORT igddim32.10046110 100460E9 8B4D 08 MOV ECX,DWORD PTR SS:[EBP+8] 100460EC 0FB791 24010000 MOVZX EDX,WORD PTR DS:[ECX+124] 100460F3 81FA 84000000 CMP EDX,84 100460F9 7C 15 JL SHORT igddim32.10046110 100460FB 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8] 100460FE 66:8B88 87000000 MOV CX,WORD PTR DS:[EAX+87] 10046105 66:C1E9 0D SHR CX,0D 10046109 66:83E1 01 AND CX,1 1004610D 884D FF MOV BYTE PTR SS:[EBP-1],CL 10046110 8A45 FF MOV AL,BYTE PTR SS:[EBP-1] 10046113 8BE5 MOV ESP,EBP 10046115 5D POP EBP 10046116 C2 0800 RETN 8
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good analysis:)
How did you resolve the indirect calls?Did you use IDA PRO?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>But the problem this code, which I just discovered, and it seems, that this code is never called,>>>
Is that code executed in kernel mode?Did you try to put breakpoint successfully on instruction entry point?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, the whole sys file, I mean the whole igddim32.sys run in kernel mode (0 ring). Now I made a
CLI
JMP to itself
and the device has been frozen.
So, it means, that the procedure called sometimes.
So, I do not understand what is the problem. I cannot disable the HotPlug detection. But I do not understand, why...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was thinking about the patching the driver.Since You can do it with windbg by issueing eb or ed command at specific virtual address.
I was thinking about the NOPing indirect function call (RtlQueryRegistryValues) and patch conditional jump with unconditional one.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I do not know if we are allowed to discuss here this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have realized that this problem arises from anti-aliasing. If anti-aliasing is completely disabled, there is no access violation.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »