This short code
include \masm32\include\masm32rt.inc
include \masm32\include\gdiplus.inc
includelib \masm32\lib\gdiplus.lib
.data
gdii GdiplusStartupInput <1>
GDItoken dd ?
.code
start proc
invoke GdiplusStartup,ADDR GDItoken,ADDR gdii,0
invoke GdiplusShutdown,GDItoken
invoke ExitProcess, eax
start endp
end
crashes in the middle of GdiplusShutdown somewhere and makes WinDbg (program and app) do this
GetContextState failed, 0x80070005
GetContextState failed, 0x80070005
GetContextState failed, 0x80070005
GetContextState failed, 0x80070005
GetContextState failed, 0x80070005
Unable to get program counter
GetContextState failed, 0x80070005
GetContextState failed, 0x80070005
Unable to get current machine context, Win32 error 0n5
Does anyone else with a different debugger get any problem?
Just run the program and let it finish.
Runs fine on Windows 10 64 bit 22H2 - in 32 bit, running in ollydbg. No crash, no exception thrown.
Both calls return 0 in eax, indicating succes.
I also made a 64 bit version. Runs fine Windows 10 22H2, x64dbg.
No crash, no exceptions, both return with 0 in rax.
Hi,sinsi
No crash, no exception thrown.
.data?
m_gdiplusToken dd ?
.code
InitGgdiplus proc
local @gdis:GdiplusStartupInput
mov @gdis.GdiplusVersion,1
mov @gdis.DebugEventCallback,0
mov @gdis.SuppressBackgroundThread,0
mov @gdis.SuppressExternalCodecs,0
invoke GdiplusStartup,addr m_gdiplusToken,addr @gdis,NULL
ret
InitGgdiplus endp
WinMainCRTStartup Proc
int 3
invoke InitGgdiplus
invoke GdiplusShutdown,m_gdiplusToken
invoke ExitProcess,NULL
WinMainCRTStartup Endp
maybe Here(gdii GdiplusStartupInput <1>) is error.
Quote from: six_L on April 12, 2025, 07:03:31 PMmaybe Here(gdii GdiplusStartupInput <1>) is error.
I have been pre-initializing GdiplusStartupInput with <1,0,0,0> more recently myself. :smiley:
No need for this that way:
mov @gdis.GdiplusVersion,1
mov @gdis.DebugEventCallback,0
mov @gdis.SuppressBackgroundThread,0
mov @gdis.SuppressExternalCodecs,0
It shoudn't be an issue in sinsi's case it is in '.data'. He iniatialzes the first member, all others are already zero on program startup. That is what I used for these tests.
For completeness, as this is the final debugger on my machine...
Runs fine on Windows 10 64 bit 22H2 - in 32 bit, running in x32dbg.
No crash, no exception thrown.
Both calls return 0 in eax, indicating succes.
Here is the windbg session
eax=0019ffcc ebx=00298000 ecx=00401000 edx=00401000 esi=00401000 edi=00401000
eip=00401000 esp=0019ff78 ebp=0019ff84 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
sinsi_gdip+0x1000:
00401000 6a00 push 0
0:000> p
eax=0019ffcc ebx=00298000 ecx=00401000 edx=00401000 esi=00401000 edi=00401000
eip=00401002 esp=0019ff74 ebp=0019ff84 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
sinsi_gdip+0x1002:
00401002 6800304000 push offset sinsi_gdip+0x3000 (00403000)
0:000> p
eax=0019ffcc ebx=00298000 ecx=00401000 edx=00401000 esi=00401000 edi=00401000
eip=00401007 esp=0019ff70 ebp=0019ff84 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
sinsi_gdip+0x1007:
00401007 6810304000 push offset sinsi_gdip+0x3010 (00403010)
0:000> p
eax=0019ffcc ebx=00298000 ecx=00401000 edx=00401000 esi=00401000 edi=00401000
eip=0040100c esp=0019ff6c ebp=0019ff84 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
sinsi_gdip+0x100c:
0040100c e81d000000 call sinsi_gdip+0x102e (0040102e)
0:000> p
ModLoad: 6eda0000 6ee22000 C:\WINDOWS\SysWOW64\uxtheme.dll
eax=00000000 ebx=00298000 ecx=00000000 edx=00030000 esi=00401000 edi=00401000
eip=00401011 esp=0019ff78 ebp=0019ff84 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
sinsi_gdip+0x1011:
00401011 ff3510304000 push dword ptr [sinsi_gdip+0x3010 (00403010)] ds:002b:00403010=10b43579
0:000> p
eax=00000000 ebx=00298000 ecx=00000000 edx=00030000 esi=00401000 edi=00401000
eip=00401017 esp=0019ff74 ebp=0019ff84 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
sinsi_gdip+0x1017:
00401017 e80c000000 call sinsi_gdip+0x1028 (00401028)
0:000> p
ModLoad: 75530000 75648000 C:\WINDOWS\SysWOW64\MSCTF.dll
GetContextState failed, 0x80070005
GetContextState failed, 0x80070005
GetContextState failed, 0x80070005
GetContextState failed, 0x80070005
GetContextState failed, 0x80070005
Unable to get program counter
GetContextState failed, 0x80070005
GetContextState failed, 0x80070005
Unable to get current machine context, Win32 error 0n5
GetContextState failed, 0x80070005
GetContextState failed, 0x80070005
Unable to get current machine context, Win32 error 0n5
GetContextState failed, 0x80070005
In the last call sinsi_gdip+0x1028 is a pointer to GdiplusShutdown
and as you can see it doesn't return, just leaves windbg in an unusual state.
BTW, it happend in every program I've downloaded, including all of yours, zedd.
No errors thrown, event viewer has no crashes.
Must be windbg.
Quote from: sinsi on April 12, 2025, 07:26:18 PMBTW, it happend in ... yours, zedd.
...
Must be windbg.
Must be, I don't write bugs. My programs just have 'features' that some folks may fail to appreciate. :joking:
But seriously, I have never used windbg. Maybe it is somehow misconfigured?
I assume there are user settings somewhere.
Have you tried it (windbg) with the default settings?
Well, the debugger in VS seems to be OK with it, so it must be windbg.
Case closed.
Hi Sinsi
I have compiled and debugged the "short code" from the first post using the VS debugger.
On my current system (Win10 Home) GdiPlusShutdown returns 0 without crashing.
Regards, Biterider
Quote from: sinsi on April 12, 2025, 08:00:39 PMWell, the debugger in VS seems to be OK with it, so it must be windbg.
Case closed.
Well at least you got that sorted out.
Is this the only time that you have had issues with windbg? Or just the first time that you noticed it?
Quote from: zedd151 on April 12, 2025, 08:14:50 PMIs this the only time that you have had issues with windbg? Or just the first time that you noticed it?
Had a problem with viewing the Registers window but reinstalling it fixed that problem, but not the gdi+ one :rolleyes:
Quote from: sinsi on April 12, 2025, 08:30:55 PMHad a problem with viewing the Registers window but reinstalling it fixed that problem, but not the gdi+ one :rolleyes:
Just be careful if you are still going to use it. Any results there may have to be verified through another debugger.
Quote from: zedd151 on April 12, 2025, 08:36:23 PMQuote from: sinsi on April 12, 2025, 08:30:55 PMHad a problem with viewing the Registers window but reinstalling it fixed that problem, but not the gdi+ one :rolleyes:
Just be careful if you are still going to use it. Any results there may have to be verified through another debugger.
I generally use the VS one, especially now :biggrin:
Win7
got stuck forever inside
invoke GdiplusShutdown,GDItoken
Quote from: greenozon on April 13, 2025, 05:44:37 PMWin7
got stuck forever inside
invoke GdiplusShutdown,GDItoken
Using Windbg? If not, under which debugger? You did not specify.
If you were running under Windbg, we already determined that Windbg was the problem. Not that call to GdiplusShutdown.
nope, Olly v2
IDA 9.1 = OK
Olly 1 stucks as well
is it kind of new anti-dbg trick? :)
Okay thanks. Now that is very interesting.
You said windows 7.
Is that 32 bit or 64? Home or Pro?
I wonder which OS sinsi was running when he initially encountered this issue.
I am thinking the problem could be OS specific, or even gdiplus version specific...
It ran fine for me under ollydbg 1.10, x32dbg, and 64 bit version under x64dbg, in Windows 10 Professional 64 bit version 22H2.
greenozon, have you experienced any problems running any programs that use gdiplus? Or is this only seen while running inside of those debuggers?
simple way to check a gdiplus.dll version, if import library was used: char szTmp[260];
HMODULE hMod = GetModuleHandle("gdiplus.dll");
GetModuleFileName(hMod, szTmp,sizeof(szTmp));
MessageBox(0, szTmp, "info", MB_OK);