Some more add'l info...
I use PowerDesk as an alternative to windows explorer. When I started my
application from within powerdesk I could reproduce the error pretty
reliably. When I stopped powerdesk and started that application from
windows explorer I could not reproduce the problem. Hmmmm. Maybe an
interaction between powerdesk (a fairly old application), the windows
ntdll.dll!RtlConvertUiListToApiList routine and the folderbrowserdialog
routines. Hmmmm. Back to the web for more research...
Doing a search on "ntdll.dll!RtlConvertUiListToApiList" in google led me to
a forum article that claimed that this routine was somehow being interacted
with by some of the Sysinternal's ProcessExplorer processes. (I run the
sysinternal process explorer virtually all the time). When I stopped
process explorer and tried again, it did indeed seem to work fine. Hmmmm.
Now I fired up Powerdesk again, and started the application from there
(still no process explorer running) and I could not reproduce the error...
Well what the heck, I fired up sysinternals process explorer and then fired
off the application from powerdesk and now I could not reproduce the error
(this was the config that I could reliably reproduce it before).
During the Google search I read that FolderBrowserDialog had a known problem
that was fixed in sp1. It had something to do with it overwriting it's
heap. Well, I found a OpenRCE trace on the win32
NTDLL->RtlConvertUiListToApiList calls and guess what routines it calls...
RtlAllocateHeap and RtlFreeHeap. Remember that when my application was in
the hang state the only thread running was the RtlConvertUiListToApiList,
and now it seems that this routine interacts with the heap. Maybe
Microsoft fixed one problem with the heap and missed another? Purely
speculation on my part, but it's pretty funny that the one thread left
running called the heap routines, and MS said that the heap was the problem
that caused the hang when the folder was > 128 chars. Coincidence? Maybe,
maybe not.
Anyway that's all I was able to find out. So, while I'm fairly sure that
one or both of PowerDesk and Sysinternals Process Explorer are somehow
interacting with the FolderBrowserDialog routine, I can't put my finger on
exactly what is happening.
Given this, can anybody shed some additional light on this?
Thanks, John
"JohnR" <Jo******@hotmail.com> wrote in message
news:BKoQe.1308$Re1.974@trndny04...
Some additional info... this is the second time I'm posting about this
issue... the first time I tried rebooting and it seemed to work. This
time it works once after the reboot, then fails again.
I used the SysInternals process explorer to try and get some add'l info.
After the application hangs, processexplorer says that there is still 1
thread running. The info it gave was 0x7c810867 followed by
NTdll.dll!RtlConvertUiListToApiList+0x276 for the thread. When I hit the
"module" button in process explorer it caused a "Properties window" (like
when you right click a directory and hit properties) to pop up against one
of my directories! Now that is weird.
I'm in no way an windows xp internals expert but I was hoping that this
might make some sense to somebody out there.
I'm at a loss here. I can't imagine that my PC configuration is so very
different that I'm seeing a problem that nobody else is seeing.
If anybody has any ideas, I would greatly appreciate them.
Thanks, John
"JohnR" <Jo******@hotmail.com> wrote in message
news:WgoQe.2198$LK.1556@trndny09...I have narrowed a problem down to a simple example. A form with two
buttons. One EXIT and one FBD. The exit button does an "END" to end the
application. The FBD button does a FolderBrowserDialog and nothing else.
When I start the application and hit EXIT everything works fine. However
if it display the FBD box (even if I don't pick a folder and immediately
hit cancel) and then try to exit one of two things happens. Either (1)
the program hangs and never exits or (2) the program 'seems' to exit but
it is still running (as seen in the tasklist), and in both cases the
program has to be killed from the tasklist.
Researching this issue, I found that there were problems associated with
FBD where paths were > 128 chars, and also if the threading model was not
STA. Both of these issues do not apply here. (my thread model is STA, and
I don't even have to pick a folder for this to happen).
I am running .NET 1.1 and my system.windows.forms.dll is ver
1.1.4322.2032.
Can anybody confirm this bug, or know of a workaround? Right now, I
have to skip the FBD entirely, and have the user just type in a folder
path (Ugh!).
Thanks for any help.
John