Win7 WINAPI,ReadThreadProfilingData,ERROR_INVALID_USER_BUFFER/1784

[MtheK]

  Can someone explain better how this structure:

;typedef struct _PERFORMANCE_DATA {
;  WORD                  Size;
;  BYTE                  Version;
;  BYTE                  HwCountersCount;
;  DWORD                 ContextSwitchCount;
;  DWORD64               WaitReasonBitMap;
;  DWORD64               CycleTime;
;  DWORD                 RetryCount;
;  DWORD                 Reserved;
;  HARDWARE_COUNTER_DATA HwCounters[MAX_HW_COUNTERS];
;} PERFORMANCE_DATA, *PPERFORMANCE_DATA;

;typedef struct _HARDWARE_COUNTER_DATA {
;  HARDWARE_COUNTER_TYPE Type;
;  DWORD                 Reserved;
;  DWORD64               Value;
;} HARDWARE_COUNTER_DATA, *PHARDWARE_COUNTER_DATA;

requires a length of 288 in 'Size' in order to make this work?
When I use 288 in my program, then the routine works correctly.

  I ended up retrying this in a loop from 32 to 4096 until either
the end of the loop, or it worked. In my case, it worked at 288.

  If the above is C, I have such a hard time trying to determine the
length of a field w/these "weird" un-typical names, to use in MASM.
That 'HwCounters' line is probably the key...
;  HARDWARE_COUNTER_DATA HwCounters[16];
so HARDWARE_COUNTER_DATA must also be 16? (288-32)/16. 4(?)+4+8.
I can't find HARDWARE_COUNTER_DATA or HARDWARE_COUNTER_TYPE in any
MASM32 file (older), even winextra.inc. The math seems to jive,
but there has to be a less-frustrating way to know the total length
when names aren't there? Thankx...

[jj2007]

Check WinNT.h in case you have a C/C++ installation, or see MSDN: HARDWARE_COUNTER_TYPE enumeration

Code Select Expand

HARDWARE_COUNTER_TYPE STRUCT
  MaxHardwareCounterType PMCCounter <>
HARDWARE_COUNTER_TYPE ENDS

HARDWARE_COUNTER_DATA STRUCT
  Type HARDWARE_COUNTER_TYPE <>
  Reserved DWORD ?
  Value DWORD64 <>
HARDWARE_COUNTER_DATA ENDS

[dedndave]

i got error 1784 the other day, in fact
not exactly related to your case, but i thought it was interesting.....

i used LoadImage with the LR_LOADFROMFILE and LR_CREATEDIBSECTION flags,
thinking i would have a "normal" DIB section to work with
i used GetObject to get the data pointer, modified some bytes, and tried to write to a BMP file

first of all...
i was loading a 256-color BMP file
LoadImage without LR_CREATEDIBSECTION loads an image in whatever dolor depth it likes ?
it seems that the color depth used is that of the current display mode (not verified, but makes sense)
by using LR_CREATEDIBSECTION, you get the native color depth of the image   ::)
an interesting, undocumented behaviour

but.....
when i tried to write the image bits back to a file, i got error 1784
the solution was to create a DIB section (CreateDIBSection),
then, BitBlt to copy the original DIB into the memory DIB,
then, i was able to write from that DIB into the file without error

so, it would seem that LR_CREATEDIBSECTION doesn't create a "real" DIB section

some insight to the ERROR_INVALID_USER_BUFFER error