Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Fixed FOLDERMONITOR causes crash

vefatica

vefatica

May
13,149
180
See below. A first FOLDERMONITOR seems to work correctly. After "FOLDERMONITOR /C" and starting another, the first change results in a single message (expected). Subsequent changes result in two messages (?). The 26th change results in a crash. If I close a second one and start a third one, the third one prints three messages per change and crashes on the 18th change. It's utterly reproducible.

Code: 
v:\> foldermonitor v:\ created modified deleted 50 echo help

v:\> echo.>> tempfile.tmp

v:\> ←[0elp
echo.>> tempfile.tmp

help
v:\> echo.>> tempfile.tmp

help
v:\> foldermonitor /c

v:\> foldermonitor v:\ created modified deleted 50 echo help

v:\> echo.>> tempfile.tmp

help
v:\> echo.>> tempfile.tmp

help
←[32;1v:\> elp
echo.>> tempfile.tmp

help
help
v:\> echo.>> tempfile.tmp

help
help
v:\> echo.>> tempfile.tmp

help
help
v:\> echo.>> tempfile.tmp

help
help
v:\> echo.>> tempfile.tmp

help
help
v:\>

Code: 
Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   tcc.exe
  Application Version:   15.0.1.52
  Application Timestamp:   51d40b07
  Fault Module Name:   tcc.exe
  Fault Module Version:   15.0.1.52
  Fault Module Timestamp:   51d40b07
  Exception Code:   c0000005
  Exception Offset:   0000414e
  OS Version:   6.1.7601.2.1.0.256.48
  Locale ID:   1033
  Additional Information 1:   07d1
  Additional Information 2:   07d19bf731583ca4adf08c5be3993ee2
  Additional Information 3:   bbd6
  Additional Information 4:   bbd6120fe5ac45d192fb7fe56d235bf5
Code: 
---------------------------
tcc.exe - Application Error
---------------------------
The instruction at 0x00000000 referenced memory at 0x00000000. The memory could not be written.


Click on OK to terminate the program
Click on CANCEL to debug the program
---------------------------
OK  Cancel   
---------------------------
 
I tried your example, but instead of using echo I used msgbox. I could not get TCC to crash.

Joe

TCC 15.01.52 Windows Vista [Version 6.0.6002]
TCC Build 52 Windows Vista Build 6002 Service Pack 2
 
Joe Caverly said:
I tried your example, but instead of using echo I used msgbox. I could not get TCC to crash.

Joe

TCC 15.01.52 Windows Vista [Version 6.0.6002]
TCC Build 52 Windows Vista Build 6002 Service Pack 2
Click to expand...
More important, did you reproduce the crash using ECHO?
Here, it crashes with MSGBOX also. It also crashes with BEEP.
 
This may give a hint as to what's happening.
Code: 
v:\> foldermonitor v:\ created modified deleted 50 echo 1

v:\> foldermonitor /c

v:\> foldermonitor v:\ created modified deleted 50 echo 2

v:\> foldermonitor /c

v:\> foldermonitor v:\ created modified deleted 50 echo 3

v:\> echo.>> tempfile.tmp

3
v:\> echo.>> tempfile.tmp

3
3
v:\> echo.>> tempfile.tmp

3
3
3
v:\>
 
No, I did not try it with echo, as I never want the results of an event to appear on the console.

Running this batch file;

Code: 
on error goto myerror
if exist results.txt del results.txt
foldermonitor /c
foldermonitor c:\utils created modified deleted 50 statusbar Test
do i = 1 to 50
  echo.>> tempfile.tmp
  foldermonitor
  echo %_folderaction >> results.txt
  echo %_foldercount >> results.txt
  echo %_foldername >> results.txt
  echo %_folderfile1 >> results.txt
  echo %_folderfile2 >> results.txt
  delay 5
enddo
goto eoj
:myerror
echo Something went wrong.
:eoj
foldermonitor /c
echo foldermonitor /c >> results.txt

...produced these results;

Code: 
MODIFIED
1
c:\utils
tempfile.tmp
ECHO is ON
MODIFIED
8
c:\utils
tempfile.tmp
ECHO is ON
MODIFIED
14
c:\utils
tempfile.tmp
ECHO is ON
MODIFIED
20
c:\utils
results.txt
ECHO is ON
MODIFIED
26
c:\utils
tempfile.tmp
ECHO is ON
MODIFIED
32
c:\utils
tempfile.tmp
ECHO is ON
MODIFIED
38
c:\utils
tempfile.tmp
ECHO is ON
MODIFIED
44
c:\utils
tempfile.tmp
ECHO is ON
MODIFIED
50
c:\utils
tempfile.tmp
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
ECHO is ON
foldermonitor /c

..but did not crash.

Joe
 
In order for me to see the crash, I must start a foldermonitor, then do "FOLDERMONITOR /C", then start it again, then make several changes in the folder.
 
I ran the following batch file;

Code: 
foldermonitor c:\utils created modified deleted 50 statusbar 1
foldermonitor /c
foldermonitor c:\utils created modified deleted 50 statusbar 2
foldermonitor /c
foldermonitor c:\utils created modified deleted 50 statusbar 3
echo.>> tempfile.tmp
echo.>> tempfile.tmp
echo.>> tempfile.tmp
foldermonitor /c

Sometimes it would crash TCC/TCMD from running it once, or twice, or any random runs. It returned the following TCMD.GPF file;

Code: 
TCC  15.01.52
Module=C:\Program Files\JPSoft\TCMD15\TakeCmd.dll
Address=1006A9B5
Exception=C0000005
EAX=FFFFFFFF  EBX=00000002  ECX=00000064  EDX=00000000
ESI=00000000  EDI=00000000  EBP=0A10FAB4  ESP=0A0FF970
CS=0000001B  DS=00000023  ES=00000023  SS=00000023
Flags=00010286

Stack:
1 : TakeCmd.dll 00000001:000699b5

In what real-world situation would I need to create a foldermonitor, and then remove all folder monitors, repetitively?

Joe
 
Joe Caverly said:
In what real-world situation would I need to create a foldermonitor, and then remove all folder monitors, repetitively?
Click to expand...
... when you, like the OP, are trying to figure out how to use FOLDERMONITOR (for one).
 
Or when you run your systems for weeks without a restart (used to be the normal way for mainframes, customer support and shared systems before MS Windows).
 
vefatica said:
See below. A first FOLDERMONITOR seems to work correctly. After "FOLDERMONITOR /C" and starting another, the first change results in a single message (expected). Subsequent changes result in two messages (?). The 26th change results in a crash. If I close a second one and start a third one, the third one prints three messages per change and crashes on the 18th change. It's utterly reproducible.
Click to expand...

Not reproducible here.

The multiple messages are expected; that's the way Windows works. (There have been several previous discussions about this.)
 
rconn said:
Not reproducible here.

The multiple messages are expected; that's the way Windows works. (There have been several previous discussions about this.)
Click to expand...
Huh? The first FOLDERMONITOR produces one message per file modification. After "FOLDERMONITOR /C" a new one produces two messages per modification (after the first). After another "FOLDERMONITOR /C" a third one produces three messages per modification (after the second). I don't think that's how Windows works. After "FOLDERMONITOR /C" and starting a new one, enough activity will cause TCC to crash. I can reproduce it at will on two computers.
 
A little snooping with ProcessExplorer shows that "FOLDERMONITOR dir ..." starts a thread ... and that thread continues to run after "FOLDERMONITOR /C" ... another "FOLDERMONITOR dir ..." starts another thread ... and that one continues after "FOLDERMONITOR /C". And so on. With several ReadDirectoryChanges going on at the same time, it's no surprise that there are more messages that expected (and eventual crashes).
 
vefatica said:
Huh? The first FOLDERMONITOR produces one message per file modification. After "FOLDERMONITOR /C" a new one produces two messages per modification (after the first). After another "FOLDERMONITOR /C" a third one produces three messages per modification (after the second). I don't think that's how Windows works.
Click to expand...

Actually, it is. Windows will send multiple update messages -- this has been beaten to death in previous threads. FOLDERMONITOR originally filtered the duplicates, but I took out the filtering a while back when a number of users (including you) said they wanted to get every message.
 
vefatica said:
A little snooping with ProcessExplorer shows that "FOLDERMONITOR dir ..." starts a thread ... and that thread continues to run after "FOLDERMONITOR /C" ... another "FOLDERMONITOR dir ..." starts another thread ... and that one continues after "FOLDERMONITOR /C". And so on. With several ReadDirectoryChanges going on at the same time, it's no surprise that there are more messages that expected (and eventual crashes).
Click to expand...

Not reproducible here. What version of Windows are you running?

Even if the thread continued to run, you wouldn't get anything back from ReadDirectoryChanges because the handle would be invalid. At worst it would loop endlessly doing nothing -- though I have in the past seen Windows crash (usually in NTDLL) when calling ReadDirectoryChanges repeatedly.
 
rconn said:
Not reproducible here. What version of Windows are you running?

Even if the thread continued to run, you wouldn't get anything back from ReadDirectoryChanges because the handle would be invalid. At worst it would loop endlessly doing nothing -- though I have in the past seen Windows crash (usually in NTDLL) when calling ReadDirectoryChanges repeatedly.
Click to expand...
I'm using Win7/32/SP1 on both machines where I tested this. I see the directory handle being closed by "FOLDERMONITOR /C" yet it's a fact that the threads continue and the number of actions sparked by a single file modification increases with the number of previously closed FOLDERMONITORs. It's interesting how that happens: if I have started/stopped five FOLDERMOMITORs and then start a sixth, the first file mod causes one action, the second two, the third three, and so on until all mods cause six actions (... until it crashes). Here's a stack reference from one of the crashes.

tcc.exe - Application Error
The instruction at 0x1006a9b5 referenced memory at 0x00000000. The memory could not be read.
 
The only way this could happen is if your system isn't returning an error when an invalid (null) handle is passed to ReadDirectoryChanges. Still not reproducible here (Win 7 or Win 8; tried it on 7 different systems) -- any chance you've got a third-party app intercepting the API? (Or that you haven't updated Windows recently?)

I've added an additional check for this case in the next build.
 
rconn said:
The only way this could happen is if your system isn't returning an error when an invalid (null) handle is passed to ReadDirectoryChanges. Still not reproducible here (Win 7 or Win 8; tried it on 7 different systems) -- any chance you've got a third-party app intercepting the API? (Or that you haven't updated Windows recently?)

I've added an additional check for this case in the next build.
Click to expand...
As I said, it's he same on two systems.
I haven't updated Windows recently (in fact, ever). Is that significant?
I also noticed this. If I merely
Code: 
v:\> foldermonitor v:\ created modified deleted 50 echo mod

v:\> foldermonitor /c
TCC's CPU usage jumps to 25% (one whole processor). If I do it again, TCC's usage jumps to 50% ... again, 75% ... again, 100%.
I suppose you have ReadDirectoryChangesW in a loop. Is there any way to get out of that loop?
 
vefatica said:
I haven't updated Windows recently (in fact, ever). Is that significant?
Click to expand...

Not significant if Windows always works perfectly for you. In this instance it's not working, so it's perhaps highly significant. :dead:

I suppose you have ReadDirectoryChangesW in a loop. Is there any way to get out of that loop?
Click to expand...

Yes, if Windows is working correctly it will fall out of the loop on an error.
 
I can no longer get it to crash. And I can't get it to produce multiple actions after FOLDERMONITORs have been closed. But the FOLDERMONITOR threads still never terminate (or at least their handles aren't closed).

I also noticed this (unrelated). When TCC starts it has 4 threads. 30 seconds later (with/without any user interaction) another thread starts. Do you know what that's all about?

P.S. (also unrelated) Did you fix ANSI's esc[K?
 
vefatica said:
I can no longer get it to crash. And I can't get it to produce multiple actions after FOLDERMONITORs have been closed. But the FOLDERMONITOR threads still never terminate (or at least their handles aren't closed).
Click to expand...

Not reproducible here.

I also noticed this (unrelated). When TCC starts it has 4 threads. 30 seconds later (with/without any user interaction) another thread starts. Do you know what that's all about?
Click to expand...

TCC is continually starting & terminating threads, for a number of reasons. Why is it significant to you?

P.S. (also unrelated) Did you fix ANSI's esc[K?
Click to expand...

I have no idea what you're referring to.
 
vefatica said:
1. Have you watched with ProcessExplorer? The thread handle does not go away on "FOLDERMONITOR /C".
Click to expand...

The thread goes away. The thread handle does not (because the function that started the thread is long gone, and trying to maintain the handle would take a lot more memory than just leaking it). If you're starting several million FOLDERMONITOR's in a single session (and you have very little memory), that might start to become an issue.

3. See http://jpsoft.com/forums/threads/ansi-esc-k.5147/
Click to expand...

Still WAD (as I said in that thread).
 
rconn said:
The thread goes away. The thread handle does not (because the function that started the thread is long gone, and trying to maintain the handle would take a lot more memory than just leaking it). If you're starting several million FOLDERMONITOR's in a single session (and you have very little memory), that might start to become an issue.

Still WAD (as I said in that thread).
Click to expand...
Handles accumulating in ProcessExplorer looks bad. Why not close it as soon as you create the thread? I'd guess it isn't used for anything.

Would you explain the console bug that prevents esc[K from working correctly? I posted some code (not much) from ANSICON which works just fine in a TCC plugin version of ANSICON.
 
vefatica said:
Handles accumulating in ProcessExplorer looks bad. Why not close it as soon as you create the thread? I'd guess it isn't used for anything.
Click to expand...

Given the hundreds of thousands of handles circulating in Windows at any given time, I'm not overly concerned about a few accumulating when somebody is using multiple FolderMonitors (which almost nobody does).

And it is used for something. By the time it's possible to delete it, it isn't available.
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate