CreateToolhelp32Snapshot v1.2 Beta * Updated

[dedndave]

out of curiosity, i wrote this little test app
posting results in here doesn't do a lot of good, because both the OS and the CPU need to be ID'ed
and - the variations of the 2 would make for messy comparison

but, it makes it easy to see which features appear on your own machine

XP MCE2005 SP3, Prescott w/htt

Code Select Expand

PF_FLOATING_POINT_PRECISION_ERRATA:  0
PF_FLOATING_POINT_EMULATED:          0
PF_COMPARE_EXCHANGE_DOUBLE:          1
PF_MMX_INSTRUCTIONS_AVAILABLE:       1
PF_PPC_MOVEMEM_64BIT_OK:             0
PF_ALPHA_BYTE_INSTRUCTIONS:          0
PF_XMMI_INSTRUCTIONS_AVAILABLE:      1
PF_3DNOW_INSTRUCTIONS_AVAILABLE:     0
PF_RDTSC_INSTRUCTION_AVAILABLE:      1
PF_PAE_ENABLED:                      1
PF_XMMI64_INSTRUCTIONS_AVAILABLE:    1
PF_SSE_DAZ_MODE_AVAILABLE:           0
PF_NX_ENABLED:                       1
PF_SSE3_INSTRUCTIONS_AVAILABLE:      0
PF_COMPARE_EXCHANGE128:              0
PF_COMPARE64_EXCHANGE128:            0
PF_CHANNELS_ENABLED:                 0
PF_XSAVE_ENABLED:                    0
PF_ARM_VFP_32_REGISTERS_AVAILABLE:   0
PF_ARM_NEON_INSTRUCTIONS_AVAILABLE:  0
PF_SECOND_LEVEL_ADDRESS_TRANSLATION: 0
PF_VIRT_FIRMWARE_ENABLED:            0
PF_RDWRFSGSBASE_AVAILABLE:           0
PF_FASTFAIL_AVAILABLE:               0
PF_ARM_DIVIDE_INSTRUCTION_AVAILABLE: 0
PF_ARM_64BIT_LOADSTORE_ATOMIC:       0
PF_ARM_EXTERNAL_CACHE_AVAILABLE:     0
PF_ARM_FMAC_INSTRUCTIONS_AVAILABLE:  0
PF_RDRAND_INSTRUCTION_AVAILABLE:     0

[adeyblue]

On the NT4 VM. CPU is reported as "Intel family 6 model 10 stepping 9" whatever that corresponds to:

Code Select Expand


PF_FLOATING_POINT_PRECISION_ERRATA: 0
PF_FLOATING_POINT_EMULATED: 1
PF_COMPARE_EXCHANGE_DOUBLE: 1
PF_MMX_INSTRUCTIONS_AVAILABLE: 1
PF_PPC_MOVEMEM_64BIT_OK: 0
PF_ALPHA_BYTE_INSTRUCTIONS: 0
PF_XMMI_INSTRUCTIONS_AVAILABLE: 0
PF_3DNOW_INSTRUCTIONS_AVAILABLE: 0
PF_RDTSC_INSTRUCTION_AVAILABLE: 0
PF_PAE_ENABLED: 0
PF_XMMI64_INSTRUCTIONS_AVAILABLE: 0
PF_SSE_DAZ_MODE_AVAILABLE: 0
PF_NX_ENABLED: 0
PF_SSE3_INSTRUCTIONS_AVAILABLE: 0
PF_COMPARE_EXCHANGE128: 0
PF_COMPARE64_EXCHANGE128: 0
PF_CHANNELS_ENABLED: 0
PF_XSAVE_ENABLED: 0
PF_ARM_VFP_32_REGISTERS_AVAILABLE: 0
PF_ARM_NEON_INSTRUCTIONS_AVAILABLE: 0
PF_SECOND_LEVEL_ADDRESS_TRANSLATION: 0
PF_VIRT_FIRMWARE_ENABLED: 0
PF_RDWRFSGSBASE_AVAILABLE: 0
PF_FASTFAIL_AVAILABLE: 0
PF_ARM_DIVIDE_INSTRUCTION_AVAILABLE: 0
PF_ARM_64BIT_LOADSTORE_ATOMIC: 0
PF_ARM_EXTERNAL_CACHE_AVAILABLE: 0
PF_ARM_FMAC_INSTRUCTIONS_AVAILABLE: 0
PF_RDRAND_INSTRUCTION_AVAILABLE: 0

On Win7 SP1 x64. IvyBridge/2020M:

Code Select Expand


PF_FLOATING_POINT_PRECISION_ERRATA: 0
PF_FLOATING_POINT_EMULATED: 0
PF_COMPARE_EXCHANGE_DOUBLE: 1
PF_MMX_INSTRUCTIONS_AVAILABLE: 1
PF_PPC_MOVEMEM_64BIT_OK: 0
PF_ALPHA_BYTE_INSTRUCTIONS: 0
PF_XMMI_INSTRUCTIONS_AVAILABLE: 1
PF_3DNOW_INSTRUCTIONS_AVAILABLE: 0
PF_RDTSC_INSTRUCTION_AVAILABLE: 1
PF_PAE_ENABLED: 1
PF_XMMI64_INSTRUCTIONS_AVAILABLE: 1
PF_SSE_DAZ_MODE_AVAILABLE: 0
PF_NX_ENABLED: 1
PF_SSE3_INSTRUCTIONS_AVAILABLE: 1
PF_COMPARE_EXCHANGE128: 1
PF_COMPARE64_EXCHANGE128: 0
PF_CHANNELS_ENABLED: 0
PF_XSAVE_ENABLED: 1
PF_ARM_VFP_32_REGISTERS_AVAILABLE: 0
PF_ARM_NEON_INSTRUCTIONS_AVAILABLE: 0
PF_SECOND_LEVEL_ADDRESS_TRANSLATION: 0
PF_VIRT_FIRMWARE_ENABLED: 0
PF_RDWRFSGSBASE_AVAILABLE: 0
PF_FASTFAIL_AVAILABLE: 0
PF_ARM_DIVIDE_INSTRUCTION_AVAILABLE: 0
PF_ARM_64BIT_LOADSTORE_ATOMIC: 0
PF_ARM_EXTERNAL_CACHE_AVAILABLE: 0
PF_ARM_FMAC_INSTRUCTIONS_AVAILABLE: 0
PF_RDRAND_INSTRUCTION_AVAILABLE: 0


I got the NT3.1 VM up after a fight but getting anything modern running on it is a nightmare. No msvcrt.dll, madness!

[dedndave]

Code Select Expand

PF_FLOATING_POINT_EMULATED: 1

i'm a little surprised to see that one   :redface:

the MSVCRT issue could be overcome by replacing the str$ macro with a routine to convert to ASCII decimal

Intel family 6 model 10 stepping 9

it's a Pentium III Xeon

[guga]

Ok guys

I updated it

Adrian (adeyblue), can you test on NT please ? I hope it is working now. I´m using IsProcessorFeaturePresent Api to check for the presence of WinNT. If this Api does not exists, then it will use the non SSE2 version.
It also will return a non SSE2 if IsProcessorFeaturePresent detects you don´t have it enable (accordying to msdn the flag is PF_XMMI64_INSTRUCTIONS_AVAILABLE)

I rebuilded the routine to check as simply this:

Code Select Expand


[CPU_Extension: D$ 0]

[CPU_EXTENSION_MMX         00_1]
[CPU_EXTENSION_SSE        00_10]
[CPU_EXTENSION_SSE2      00_100]
[CPU_EXTENSION_SSE3     00_1000]
[CPU_EXTENSION_SSSE3   00_10000]
[CPU_EXTENSION_SSE41  00_100000]
[CPU_EXTENSION_SSE42 00_1000000]

Proc SSECheck:
    Uses ebx, esi, edi
    Local @hpfIsProcessorFeaturePresent

    call 'KERNEL32.LoadLibraryA' {B$ 'kernel32.dll', 0}
    call 'KERNEL32.GetProcAddress' eax, {B$ 'IsProcessorFeaturePresent', 0} | mov D@hpfIsProcessorFeaturePresent eax

    .If eax <> 0
        C_call D@hpfIsProcessorFeaturePresent &PF_XMMI64_INSTRUCTIONS_AVAILABLE
        If eax = 0
            mov D$CPU_Extension 0
        Else
            mov D$CPU_Extension CPU_EXTENSION_SSE2
        End_If
    .Else
        mov D$CPU_Extension 0
    .End_If

EndP


Later i´ll try to see better what Dave did and why it is not working on yours.

Btw...Dave , as far i remember there is a C function made by intel that can check this. (I´m uploading here for you a zip file that checks SSE4.2. Maybe you can find the other c code in intel reference manuals)

[guga]

Damn M$, the heapxx functions are giving me on my nerves. Only one function missing (Heap32Next) and again, i see bugs (defined as such in their own Source since win NT...Which btw...is not fixed in XP yet and most probably nor fixed in win7 or above). The computing of the heap segments are made by guess, even thinking that they are just formed as an array of structures mapped from ntdll.dll.

I don´t know how M$ development team made such a mess on their own code. Don´t they communicate each other ? I mean, the guy that created the toolhelp functinos didn´t talked to the ones that made the RTL memory mapping/creation functions, such RtlCreateQueryDebugBuffer ???

I´ll port that stuff, but will definitely need to build other functions to reestructure the SNAPSHOT structure to it be properly mapped so the pointers and flags for the toolhelp can be correctly defined. I personally don´t care much what taskmanager says, because underneath it uses apis that "guesses" the pointers from memory, instead simply computing them.

[FORTRANS]

Hi Dave,

   Results posted due to the P-MMX not reporting MMX available.
And on which processor did the RDTSC instruction start?  P-Pro?

Code Select Expand

P-MMX

PF_FLOATING_POINT_PRECISION_ERRATA: 0
PF_FLOATING_POINT_EMULATED: 0
PF_COMPARE_EXCHANGE_DOUBLE: 0
PF_MMX_INSTRUCTIONS_AVAILABLE: 0
PF_PPC_MOVEMEM_64BIT_OK: 0
PF_ALPHA_BYTE_INSTRUCTIONS: 0
PF_XMMI_INSTRUCTIONS_AVAILABLE: 0
PF_3DNOW_INSTRUCTIONS_AVAILABLE: 0
PF_RDTSC_INSTRUCTION_AVAILABLE: 0
PF_PAE_ENABLED: 0
PF_XMMI64_INSTRUCTIONS_AVAILABLE: 0
PF_SSE_DAZ_MODE_AVAILABLE: 0
PF_NX_ENABLED: 0
PF_SSE3_INSTRUCTIONS_AVAILABLE: 0
PF_COMPARE_EXCHANGE128: 0
PF_COMPARE64_EXCHANGE128: 0
PF_CHANNELS_ENABLED: 0
PF_XSAVE_ENABLED: 0
PF_ARM_VFP_32_REGISTERS_AVAILABLE: 0
PF_ARM_NEON_INSTRUCTIONS_AVAILABLE: 0
PF_SECOND_LEVEL_ADDRESS_TRANSLATION: 0
PF_VIRT_FIRMWARE_ENABLED: 0
PF_RDWRFSGSBASE_AVAILABLE: 0
PF_FASTFAIL_AVAILABLE: 0
PF_ARM_DIVIDE_INSTRUCTION_AVAILABLE: 0
PF_ARM_64BIT_LOADSTORE_ATOMIC: 0
PF_ARM_EXTERNAL_CACHE_AVAILABLE: 0
PF_ARM_FMAC_INSTRUCTIONS_AVAILABLE: 0
PF_RDRAND_INSTRUCTION_AVAILABLE: 0

Press any key to continue ...

P-III

PF_FLOATING_POINT_PRECISION_ERRATA:  0
PF_FLOATING_POINT_EMULATED:          0
PF_COMPARE_EXCHANGE_DOUBLE:          1
PF_MMX_INSTRUCTIONS_AVAILABLE:       1
PF_PPC_MOVEMEM_64BIT_OK:             0
PF_ALPHA_BYTE_INSTRUCTIONS:          0
PF_XMMI_INSTRUCTIONS_AVAILABLE:      1
PF_3DNOW_INSTRUCTIONS_AVAILABLE:     0
PF_RDTSC_INSTRUCTION_AVAILABLE:      1
PF_PAE_ENABLED:                      0
PF_XMMI64_INSTRUCTIONS_AVAILABLE:    0
PF_SSE_DAZ_MODE_AVAILABLE:           0
PF_NX_ENABLED:                       0
PF_SSE3_INSTRUCTIONS_AVAILABLE:      0
PF_COMPARE_EXCHANGE128:              0
PF_COMPARE64_EXCHANGE128:            0
PF_CHANNELS_ENABLED:                 0
PF_XSAVE_ENABLED:                    0
PF_ARM_VFP_32_REGISTERS_AVAILABLE:   0
PF_ARM_NEON_INSTRUCTIONS_AVAILABLE:  0
PF_SECOND_LEVEL_ADDRESS_TRANSLATION: 0
PF_VIRT_FIRMWARE_ENABLED:            0
PF_RDWRFSGSBASE_AVAILABLE:           0
PF_FASTFAIL_AVAILABLE:               0
PF_ARM_DIVIDE_INSTRUCTION_AVAILABLE: 0
PF_ARM_64BIT_LOADSTORE_ATOMIC:       0
PF_ARM_EXTERNAL_CACHE_AVAILABLE:     0
PF_ARM_FMAC_INSTRUCTIONS_AVAILABLE:  0
PF_RDRAND_INSTRUCTION_AVAILABLE:     0

Press any key to continue ...

Regards,

Steve N.

[MichaelW]

IIRC, for the Intel processors RDTSC started with the original Pentium.

[dedndave]

it's sort of a mess - that's why it does little good to collect data in the forum

you have to consider the OS version when the IsProcessFeaturePresent function began supporting each value
so - a feature might well be available and in use - but not reported for the OS/SP level you are using

a good approach might be to consider the OS and SP
then stop listing features at a certain spot in the list   :P
the last 4 or 5 only showed up in windows 8, for example

it really makes the function somewhat useless, because you'd need some kind of "reporting matrix" to validate the results
if a bit is set, you know it's supported - otherwise, you know less than you did before - lol

it might be useful for determining if AVX is supported, though

[dedndave]

hindsight, of course
but, it would be nicer if they had returned -1 for unsupported index values   :t

[FORTRANS]

Hi,

IIRC, for the Intel processors RDTSC started with the original Pentium.

   Thanks, that's what I thought.  So the reported results were
wrong.

it's sort of a mess - that's why it does little good to collect data in the forum

   Oh.  Should have believed you then, and not posted.

you have to consider the OS version when the IsProcessFeaturePresent function began supporting each value
so - a feature might well be available and in use - but not reported for the OS/SP level you are using

[...]

it really makes the function somewhat useless, because you'd need some kind of "reporting matrix" to validate the results
if a bit is set, you know it's supported - otherwise, you know less than you did before -

   Well did Windows 98 predate the Pentium?  In which case the
results may make sense.  (No, not really.)

Thanks,

Steve N.

[dedndave]

   Well did Windows 98 predate the Pentium?  In which case the
results may make sense.  (No, not really.)

no   

but, consider the timeline....
at some point, the ms programmers decided it was pertinent for this function to report it
and so, they added the PF_RDTSC_INSTRUCTION_AVAILABLE index
that obviously came after windows 98 and the pentium

it would make a lot more sense if it had returned -1   :t

[adeyblue]

Adrian (adeyblue), can you test on NT please ? I hope it is working now.

Sorry :-( RichEdit10AnsiWndProc doesn't exist in riched20.dll. All that dll exports on NT4 is
_DllMain@12
CreateTextServices
IID_IRichEditOle
IID_IRichEditOleCallback
IID_ITextHost
IID_ITextHost2
IID_ITextServices

I replaced it the dll with the version from Win 2000 and it works, did notice one bug though. For the [System Process] it ends up enumeratng the modules of the current process.

Code Select Expand


=====================================================
PROCESS NAME:  [System Process]
=====================================================
_____________________________________________________
Warning !!!! The following error ocurred:
Error Title: 'Api OpenProcess error'
Error Message: 'The parameter is incorrect.'
_____________________________________________________
_____________________________________________________

  Process ID        =        0 (0x00000000) <---------------- System process
  Thread Count      =        1
  Parent Process ID =        0 (0x00000000)
  Priority Base     =        0
  Priority Class    =        Error. See message above
_____________________________________________________

MODULE NAME:  Gugac2.exe
_____________________________________________________
  Executable        =        C:\share\Gugac2.exe
_____________________________________________________

  Process ID        =        1584 (0x00000630) <---------------- Current process
  Ref Count (g)     =        Not meanfull (0x0000FFFF)
  Ref Count (p)     =        Not meanfull (0x0000FFFF)
  Base Address      =        0x00400000
  Base Size         =        40960
_____________________________________________________

MODULE NAME:  ntdll.dll
_____________________________________________________
  Executable        =        C:\WINDOWS\system32\ntdll.dll
_____________________________________________________

  Process ID        =        1584 (0x00000630) <---------------- Current process
  Ref Count (g)     =        Not meanfull (0x0000FFFF)
  Ref Count (p)     =        Not meanfull (0x0000FFFF)
  Base Address      =        0x7C900000
  Base Size         =        716800
_____________________________________________________

It's probably because of CreateToolhelp32Snapshot(TH32CS_SNAPMODULE) thinking the process id of 0 means the current process.

[guga]

Sorry :-( RichEdit10AnsiWndProc doesn't exist in riched20.dll. All that dll exports on NT4 is
_DllMain@12
CreateTextServices
IID_IRichEditOle
IID_IRichEditOleCallback
IID_ITextHost
IID_ITextHost2
IID_ITextServices

I replaced it the dll with the version from Win 2000 and it works, did notice one bug though. For the [System Process] it ends up enumeratng the modules of the current process.

wahoooooo

Then the problem is on the usage of richedit on the rtf demo functions and not the rebuilded toolhelp apis functions :) :):):) (I´ll review the rtf fix once i succeed to fix the Heap32Next problem i´m currently doing.
Anyway, it is good to know the rebuilded Apis are fully working on NT now, the same way as the original version.

About enumerating the current system. Excellent, this happens here too. It seems to be an error on M$ example i ported and not the rebuilded Api functions.

I ported the functions examples as in here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686701%28v=vs.85%29.aspx

If i compiled the C function in VS it will give me these results too (The same ones as in both gui versions):

Code Select Expand


=====================================================
PROCESS NAME:  [System Process]
-------------------------------------------------------
  WARNING: OpenProcess failed with error 87 (The parameter is incorrect)
  Process ID        = 0x00000000
  Thread count      = 8
  Parent process ID = 0x00000000
  Priority base     = 0

     MODULE NAME:     Snapshot.exe
     Executable     = D:\RosAsm\RosAsm\ToolHelpLib\Debug\Snapshot.exe
     Process ID     = 0x0000B250
     Ref count (g)  = 0xFFFF
     Ref count (p)  = 0xFFFF
     Base address   = 0x00400000
     Base size      = 32768

     MODULE NAME:     ntdll.dll
     Executable     = C:\WINDOWS\system32\ntdll.dll
     Process ID     = 0x0000B250
     Ref count (g)  = 0xFFFF
     Ref count (p)  = 0xFFFF
     Base address   = 0x7C900000
     Base size      = 729088



Can you check this source for me ? I mean, it does as it expects, or there is actually a bug in the original Api that i also reproduced it after porting it ? I would like to be sure either it is a bug on M$ example or in the Apis themselves (If it is a bug on the api, i can try fixing them, but... it seems more like an error on the C example).

I´m amazed the rebuilded Apis worked as expected on Win NT. It means that they are being correctly ported to assembly in order for me to do a proper dll containing them. Once i finish Heap32Next i´ll try to make a function similar to Toolhelp32ReadProcessMemory (Which is already rebuilded, btw) but, instead reading the memory from a specific address it will export the whole SNAPSHOT structure to the user analyse it. Or create a Toolhelp32ReadProcessMemoryEx function where it returns the total amount of bytes necessary for the buffer, in case of failures or also under user choice.

For instance, Toolhelp32ReadProcessMemoryEx can use lpBaseAddress as a flag to determine the amount of allocated memory. So if you set lpBaseAddress = 0, it returns the amount of bytes to you use either in Toolhelp32ReadProcessMemory or in Toolhelp32ReadProcessMemoryEx

[adeyblue]

About enumerating the current system. Excellent, this happens here too. It seems to be an error on M$ example i ported and not the rebuilded Api functions.

So it is. I didn't run the one using the MS functions when I tried it on XP so I didn't notice that it did it as well. So yeah, it appears that it's another bug to chalk up to MSDN. Because I had nothing better to do, I went and looked to see if CreateToolhelp32Snapshot(MODULES, 0) meant the current process on Win95, which is most likely when that example was written, and it did. So it's that sample that's buggy and your replacements are perfectly fine.

Don't know if you really care about NT 3.1 but I checked ntdll.dll's exports against what your exe imports and unfortunately none of the RTL_DEBUG_INFORMATION related functions exist.

[guga]

Indeed, NT 3.1 does not seems to have the following apis:

RtlCreateQueryDebugBuffer
RtlDestroyQueryDebugBuffer
RtlQueryProcessDebugInformation


I took a fast look onto mine ntdll (XP) for this functions, and it seems it can also be ported since it uses others apis that do exist on NT 3.1. So, i´ll try porting them too :)

Many tks for the listing :)


Btw: since some of those functions uses TEB, i´ll probably need to add a routine that checks for which WindowZZZ version it is currently being used. ::)
In general i take the information about TEb from Nirsoft, or UNdocumented Internals but...i just found a website from Michal Trojnara which seems to be far more complete and accurated accodying to the sources i have of winNT, Win2000 and WinXP educacional. His links are: Link 01, Link 02, Link 03