narkive is for sale. Interested? (dismiss)
Discussion:
TreeResetNamedSecurityInfo crashes with callback
(too old to reply)
Lachoneus
2004-11-10 16:48:59 UTC
Permalink
I wrote a short program to fix permissions in an XP Home simple file
share. I just retrieve the owner, group, and DACL for the folder
using GetNamedSecurityInfo(), and then pass the data retrieved
directly to TreeResetNamedSecurityInfo().

It works just fine when I pass NULL to TreeResetNamedSecurityInfo()
for fnProgress. But if I supply a progress callback function--even an
empty one--it will run for awhile and then crash deep inside
NTMARTA.DLL.

Baseline progress callback (still causing a crash) is as follows, with
the signature taken straight out of MSDN:

VOID ProgressCallback(
IN LPWSTR pObjectName,
IN DWORD Status,
IN OUT PPROG_INVOKE_SETTING pInvokeSetting,
IN PVOID Args,
IN BOOL SecuritySet
)
{
}

TreeResetNamedSecurityInfo() is invoked as follows:

TreeResetNamedSecurityInfo(
filename,
SE_FILE_OBJECT,
DACL_SECURITY_INFORMATION | GROUP_SECURITY_INFORMATION |
OWNER_SECURITY_INFORMATION,
psidOwner,
psidGroup,
pDacl,
NULL,
FALSE,
ProgressCallback,
ProgressInvokeEveryObject,
NULL);

Simply changing ProgressInvokeEveryObject to ProgressInvokeNever
prevents the crash.

Any clues?
Yu Chen [MS]
2004-11-12 00:17:28 UTC
Permalink
I am not able to reproduce the crash on XP SP2 machine. Could you let me
know the OS version you ran your program on? How deep is the folder you
tried to reset the security setting? If possible, could you run it under
debugger and send the debugger output when the crash happens?
--
Yu Chen [MS]
This posting is provided "AS IS" with no warranties, and confers no rights.
Post by Lachoneus
I wrote a short program to fix permissions in an XP Home simple file
share. I just retrieve the owner, group, and DACL for the folder
using GetNamedSecurityInfo(), and then pass the data retrieved
directly to TreeResetNamedSecurityInfo().
It works just fine when I pass NULL to TreeResetNamedSecurityInfo()
for fnProgress. But if I supply a progress callback function--even an
empty one--it will run for awhile and then crash deep inside
NTMARTA.DLL.
Baseline progress callback (still causing a crash) is as follows, with
VOID ProgressCallback(
IN LPWSTR pObjectName,
IN DWORD Status,
IN OUT PPROG_INVOKE_SETTING pInvokeSetting,
IN PVOID Args,
IN BOOL SecuritySet
)
{
}
TreeResetNamedSecurityInfo(
filename,
SE_FILE_OBJECT,
DACL_SECURITY_INFORMATION | GROUP_SECURITY_INFORMATION |
OWNER_SECURITY_INFORMATION,
psidOwner,
psidGroup,
pDacl,
NULL,
FALSE,
ProgressCallback,
ProgressInvokeEveryObject,
NULL);
Simply changing ProgressInvokeEveryObject to ProgressInvokeNever
prevents the crash.
Any clues?
b***@gmail.com
2014-08-06 12:47:17 UTC
Permalink
Post by Lachoneus
It works just fine when I pass NULL to TreeResetNamedSecurityInfo()
for fnProgress. But if I supply a progress callback function--even an
empty one--it will run for awhile and then crash deep inside
NTMARTA.DLL.
(Hopefully this original poster has found a workaround after ten
years, but I just ran into this and thought I'd post a response for
anyone else who has this problem.)

The issue is the progress function needs to use the __stdcall calling
convention (callee cleans the stack). Unfortunately it is declared
without any calling convention, so it defaults to whatever your
compiler is currently using, which is usually __cdecl (caller cleans
the stack) these days. This causes the stack pointer to keep
decrementing with every call until bad things happen.

The solution is to declare your function with __stdcall. This will
cause a compilation error where you're passing the function pointer
to TreeResetNamedSecurityInfo() because it thinks it's a mismatch,
but you can get around that by casting the function pointer to
FN_PROGRESS.

Loading...