Driver bug (AV in igdumd32.dll, DirectX 9 related) - Page 2

oev_nsk · ‎12-09-2009

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.

Philip_T_Intel1 · ‎06-02-2010

have you recompiled your app with full debug info, run using the debug runtime turned up to max, and used the D3D debug symbols?

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?

kevink_gb · ‎07-20-2010

We've been seeing this exact error as well on a significant number of users. The system I'm testing on is running 64 bit Windows 7 Ultimate, but running in 32 bit mode with 3 GB RAM. The card is a 'Mobile Intel 965 Express Chipset Family', driver version 8.15.10.1930. DirectX is June 2010 (March 2009 had identical results).

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

Philip_T_Intel1 · ‎07-20-2010

Is it possible you have a heap overrun and have corrupted blocks?

http://blogs.msdn.com/b/jiangyue/archive/2010/03/16/windows-heap-overrun-monitoring.aspx

may be of some use.

kevink_gb · ‎07-20-2010

Thanks for the quick reply Philip.

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

lheminez · ‎03-22-2012

I concur, please assist these developers in any way possible. I'm close to *shudder* trying out 3rd party driver download sites because I'm looking for igdumd32.dll because it doesn't seem to be installed in my Windows 7 64 bit system. I just bought this laptop new a few months ago, and am finding it very frustraiting trying to play any 3d game/application that is worth it's salt. The hardware can render the scene, it's definently powerful enough and it can do so on other operating systems (XP) as has been pointed out several times in this thread.

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.

Alexander_S_9 · ‎12-24-2013

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.

Bernard · ‎12-24-2013

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?

Alexander_S_9 · ‎01-07-2014

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.

MFalk1 · ‎04-10-2014

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....

MFalk1 · ‎04-14-2014

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.

Bernard · ‎04-14-2014

>>>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

Bernard · ‎04-14-2014

	
				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.

MFalk1 · ‎04-15-2014

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

Bernard · ‎04-15-2014

Good analysis:)

How did you resolve the indirect calls?Did you use IDA PRO?

Bernard · ‎04-15-2014

>>>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?

MFalk1 · ‎04-15-2014

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...

Bernard · ‎04-15-2014

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.

Bernard · ‎04-15-2014

I do not know if we are allowed to discuss here this.

Mazaheri__Mohammad · ‎04-10-2020

I have realized that this problem arises from anti-aliasing. If anti-aliasing is completely disabled, there is no access violation.