|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Perplexing Problem - Need Helpwritten in VB6 with some API calls (SHCreateDirectory and SHFileOperation). Since that time there has been an intermittent and impossible to find problem that has haunted me. Sometimes it disappears for months only to reappear and bite me again. I need your help because I'm the only developer and I have no one to bounce ideas off of and I can think of no better group of people to turn to for assistance. The short description is that some error or event occurs that causes the call stack to unwind without any logging or raising an error or returning to the called procedures. The application is used to scan batches of documents to tiff files. Barcoded sheets are used to delineate batches and documents within a batch. Paper is loaded into the scanner and the start scan button is clicked. The button click event handler calls a routine that starts the scan (handled by an ActiveX EXE that wraps the Kodak imgScan OCX) then enters a loop looking for pages to display to the scan operator. The rest is then handled by events raised by the ActiveX EXE . Once the scan is complete, the Scan_Done event is raised and the processing of the scanned images begins. A blank page detection procedure is called followed by a barcode detection procedure. Up to this point everything is working flawlessly. The next thing that happens is that the pages are moved into batches and documents (Folders and sub-folders) based on the barcodes and blank pages are deleted. This process is called "Assembly" and this is where the problem occurs. Prior to calling assembly I log that it is going to Assembly and I also log return from assembly. Occasionally, the assembly process just quits and the application ends up in the form's idle message loop doing nothing. All procedures have error handlers that log errors. No handled or unhandled errors are logged, the return from Assembly is not logged either. There is an ActiveX DLL that handles all of the folder creation, file moving/deleting and database updates. Under what possible scenario can the application get several levels back up the call stack without returning to the calling procedures. I suppose if I was reading this I would say it's impossible, but somehow it's happening. If anyone has any ideas, troubleshooting suggestions or even off-the-wall suggestions I would welcome hearing them. I can provide more info to anyone that is willing to lend a hand. -- Al Reid
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> skrev i meddelandet Since no errors rised, my quarter is on the job is somehow reported as news:eiua4Rc9JHA.4204@TK2MSFTNGP04.phx.gbl... >I have a scanning application that I wrote back in the end of 2006. I was >written in VB6 with some API calls (SHCreateDirectory and SHFileOperation). >Since that time there has been an intermittent and impossible to find >problem that has haunted me. Sometimes it disappears for months only to >reappear and bite me again. > > I need your help because I'm the only developer and I have no one to > bounce ideas off of and I can think of no better group of people to turn > to for assistance. > > The short description is that some error or event occurs that causes the > call stack to unwind without any logging or raising an error or returning > to the called procedures. > > The application is used to scan batches of documents to tiff files. > Barcoded sheets are used to delineate batches and documents within a > batch. Paper is loaded into the scanner and the start scan button is > clicked. The button click event handler calls a routine that starts the > scan (handled by an ActiveX EXE that wraps the Kodak imgScan OCX) then > enters a loop looking for pages to display to the scan operator. The rest > is then handled by events raised by the ActiveX EXE . Once the scan is > complete, the Scan_Done event is raised and the processing of the scanned > images begins. A blank page detection procedure is called followed by a > barcode detection procedure. Up to this point everything is working > flawlessly. The next thing that happens is that the pages are moved into > batches and documents (Folders and sub-folders) based on the barcodes and > blank pages are deleted. This process is called "Assembly" and this is > where the problem occurs. Prior to calling assembly I log that it is going > to Assembly and I also log return from assembly. Occasionally, the > assembly process just quits and the application ends up in the form's > idle message loop doing nothing. All procedures have error handlers that > log errors. No handled or unhandled errors are logged, the return from > Assembly is not logged either. > > There is an ActiveX DLL that handles all of the folder creation, file > moving/deleting and database updates. > > Under what possible scenario can the application get several levels back > up the call stack without returning to the calling procedures. I suppose > if I was reading this I would say it's impossible, but somehow it's > happening. > > If anyone has any ideas, troubleshooting suggestions or even off-the-wall > suggestions I would welcome hearing them. I can provide more info to > anyone that is willing to lend a hand. > > -- > Al Reid > > finished even though it's not. /Henning "Henning" <computer_h***@coldmail.com> wrote in message Henning,news:%23orDBZe9JHA.4176@TK2MSFTNGP02.phx.gbl... > >> >> > > Since no errors rised, my quarter is on the job is somehow reported as > finished even though it's not. > > /Henning > > Thanks for the feedback, but it's not that simple. I have the following in the calling procedure (Scan_Done event): goLogger.LogEvent "Off to Assembly" call Assembly(oWorkArray) goLogger.LogEvent "Back from Assembly" The "Off to Assembly" in logged to the file but the "Back from Assembly" is not. If the assembly procedure thought it was done it would return back to the caller. It does not. If there was an error thrown in the assembly procedure it would be logged by the error handler then return to the event procedure and log the return message. There are also other logging statements in the code that are written to the file after a successful return from assembly. Nothing is logged after going to Assembly, it just ends up in the form idle message loop waiting for user input. Got any more quarters to spend? :o) -- Al Reid
Show quote
Hide quote
"Al Reid" <ar***@reidDASHhome.com> wrote What would happen if there was an error in your logger routines?> > Since no errors rised, my quarter is on the job is somehow reported as > > finished even though it's not. > > I have the following in the calling procedure (Scan_Done event): > > goLogger.LogEvent "Off to Assembly" > call Assembly(oWorkArray) > goLogger.LogEvent "Back from Assembly" > > The "Off to Assembly" in logged to the file but the "Back from Assembly" is > not. If the assembly procedure thought it was done it would return back to > the caller. It does not. If there was an error thrown in the assembly > procedure it would be logged by the error handler then return to the event > procedure and log the return message. There are also other logging > statements in the code that are written to the file after a successful > return from assembly. Nothing is logged after going to Assembly, it just > ends up in the form idle message loop waiting for user input. > > Got any more quarters to spend? :o) Like, something preventing the log to be written. That would help explain why you don't see log entries as you expect.... LFS
Show quote
Hide quote
"Larry Serflaten" <serfla***@usinternet.com> wrote in message Larry,news:%231Hmuvf9JHA.3544@TK2MSFTNGP04.phx.gbl... > > "Al Reid" <ar***@reidDASHhome.com> wrote > >> > Since no errors rised, my quarter is on the job is somehow reported as >> > finished even though it's not. >> >> I have the following in the calling procedure (Scan_Done event): >> >> goLogger.LogEvent "Off to Assembly" >> call Assembly(oWorkArray) >> goLogger.LogEvent "Back from Assembly" >> >> The "Off to Assembly" in logged to the file but the "Back from Assembly" >> is >> not. If the assembly procedure thought it was done it would return back >> to >> the caller. It does not. If there was an error thrown in the assembly >> procedure it would be logged by the error handler then return to the >> event >> procedure and log the return message. There are also other logging >> statements in the code that are written to the file after a successful >> return from assembly. Nothing is logged after going to Assembly, it just >> ends up in the form idle message loop waiting for user input. >> >> Got any more quarters to spend? :o) > > > What would happen if there was an error in your logger routines? > Like, something preventing the log to be written. That would help > explain why you don't see log entries as you expect.... > > LFS > If there was an error in the logging code it would be raided to the caller and handled there. I'm 99.99% sure that there isn't a problem in the logger class. I've been using it for over 9 years in countless applications and have never had a problem with it anywhere else. Yes, I agree that it's usually a simple explanation, but I don't think this is it. If I start a scan again after the problem the info is written to the log on the subsequent run without re-initializing the log class. Much of the logging was added after the problem was discovered. I suppose I could replace the logging with message boxes, but I'm not sure this would change anything. -- Al Reid "Al Reid" <arei***@reidDASHhome.com> wrote in message You can use OutputDebugString() as another level of redundancy. It prints news:eV9R3zk9JHA.2872@TK2MSFTNGP05.phx.gbl... > I suppose I could replace the logging with message boxes, but I'm not sure > this would change anything. the string to an external debug viewer. Here is one that is free and does not require installation: DebugView: http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx Declaration: Public Declare Sub OutputDebugString Lib "kernel32" Alias _ "OutputDebugStringA" (ByVal lpOutputString As String) Usage: OutputDebugString "ABC" Wrapper sub: Public Sub DebugPrint(ByRef s As String) OutputDebugString s End Sub "Al Reid" <arei***@reidDASHhome.com> wrote Ok, I can only take that at face value, you know the code better....> If there was an error in the logging code it would be raided to the caller > and handled there. I'm 99.99% sure that there isn't a problem in the logger > class. > If at all possible, I'd rather log timestamps and milestones during> If I start a scan again after the problem the info is written to the log on > the subsequent run without re-initializing the log class. Much of the > logging was added after the problem was discovered. I suppose I could > replace the logging with message boxes, but I'm not sure this would change > anything. the assembly process. If you find out exactly where it skips out, or if it skips out in different places, it might give you a clue where else to look.... LFS "Larry Serflaten" <serfla***@usinternet.com> wrote in message I con provide the code if you want to see it. When I inherited the code it news:%23NUE7Nl9JHA.1252@TK2MSFTNGP04.phx.gbl... > > "Al Reid" <arei***@reidDASHhome.com> wrote > >> If there was an error in the logging code it would be raided to the >> caller >> and handled there. I'm 99.99% sure that there isn't a problem in the >> logger >> class. > > Ok, I can only take that at face value, you know the code better.... > used FSO and only flushed to disk when the program closed. Not really useful if the program crashed and burned. I removed the FSO and replaced it with native VB file handling and the file is opened, written and closed on each call to LogEvent. Show quoteHide quote >> Larry,>> If I start a scan again after the problem the info is written to the log >> on >> the subsequent run without re-initializing the log class. Much of the >> logging was added after the problem was discovered. I suppose I could >> replace the logging with message boxes, but I'm not sure this would >> change >> anything. > > If at all possible, I'd rather log timestamps and milestones during > the assembly process. If you find out exactly where it skips out, or > if it skips out in different places, it might give you a clue where else > to > look.... > > LFS > I have all of that and it is turned on by starting the application with a /D command line switch and writes to a separate debug log file. It has never failed while debug logging is turned on. That is what is making this so hard to solve. Give me a repeatable problem and I can solve it in minutes. This intermittent problem that seems to defy logic is driving me crazy. Debug logging also has a noticeable impact on the performance of the application. A single scan batch can create over 5000 log entries. Maybe I have too many log calls, but I tried to log everything that was going on (page retrieved, barcode detected, created batch folder, created document folder, move page, delete blank page, etc.) -- Al Reid
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> skrev i meddelandet This is something to chew on.news:excziVl9JHA.1492@TK2MSFTNGP03.phx.gbl... > > "Larry Serflaten" <serfla***@usinternet.com> wrote in message > news:%23NUE7Nl9JHA.1252@TK2MSFTNGP04.phx.gbl... >> >> "Al Reid" <arei***@reidDASHhome.com> wrote >> >>> If there was an error in the logging code it would be raided to the >>> caller >>> and handled there. I'm 99.99% sure that there isn't a problem in the >>> logger >>> class. >> >> Ok, I can only take that at face value, you know the code better.... >> > > I con provide the code if you want to see it. When I inherited the code > it used FSO and only flushed to disk when the program closed. Not really > useful if the program crashed and burned. I removed the FSO and replaced > it with native VB file handling and the file is opened, written and closed > on each call to LogEvent. > >>> >>> If I start a scan again after the problem the info is written to the log >>> on >>> the subsequent run without re-initializing the log class. Much of the >>> logging was added after the problem was discovered. I suppose I could >>> replace the logging with message boxes, but I'm not sure this would >>> change >>> anything. >> >> If at all possible, I'd rather log timestamps and milestones during >> the assembly process. If you find out exactly where it skips out, or >> if it skips out in different places, it might give you a clue where else >> to >> look.... >> >> LFS >> > > Larry, > > I have all of that and it is turned on by starting the application with a > /D command line switch and writes to a separate debug log file. It has > never failed while debug logging is turned on. That is what is making > this so hard to solve. Give me a repeatable problem and I can solve it in > minutes. This intermittent problem that seems to defy logic is driving me > crazy. The /D logging is not using goLogger.LogEvent? Seems to me goLogger.LogEvent somehow does not write to the log. Timing issue? > Temporarily narrow down to just Assembly?> Debug logging also has a noticeable impact on the performance of the > application. A single scan batch can create over 5000 log entries. Maybe > I have too many log calls, but I tried to log everything that was going on > (page retrieved, barcode detected, created batch folder, created document > folder, move page, delete blank page, etc.) Show quoteHide quote > > -- > Al Reid > > /Henning
Show quote
Hide quote
"Henning" <computer_h***@coldmail.com> wrote in message The /D creates a new instance of the cLog class and logs info to a separate news:%23NU0xol9JHA.1540@TK2MSFTNGP02.phx.gbl... > >> >> Larry, >> >> I have all of that and it is turned on by starting the application with a >> /D command line switch and writes to a separate debug log file. It has >> never failed while debug logging is turned on. That is what is making >> this so hard to solve. Give me a repeatable problem and I can solve it >> in minutes. This intermittent problem that seems to defy logic is driving >> me crazy. > > This is something to chew on. > The /D logging is not using goLogger.LogEvent? > Seems to me goLogger.LogEvent somehow does not write to the log. > Timing issue? > file using the LogEvent method. The other stuff is still written to the Error Log file. The /D jusr enables another set of detailed debug info to be written to a separate file. If gblnDoDebugLogs Then goDebugLog.LogEvent "Starting Assembly on Batch " & Batch.Name >> Yes. In fact, this was added just to try to solve this problem. I'm going >> Debug logging also has a noticeable impact on the performance of the >> application. A single scan batch can create over 5000 log entries. >> Maybe I have too many log calls, but I tried to log everything that was >> going on (page retrieved, barcode detected, created batch folder, created >> document folder, move page, delete blank page, etc.) > > Temporarily narrow down to just Assembly? > to run with it turned on again today to see if I can catch one. We ran for a whole week once and the problem never occurred. The next week it came back. This is also a reason why I don't think the problem is related to the Logger class. Show quoteHide quote >> >> -- >> Al Reid >> >> > /Henning > >
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> wrote in message I just counted and there are 35 debug logging statements in the Assembly news:excziVl9JHA.1492@TK2MSFTNGP03.phx.gbl... > > "Larry Serflaten" <serfla***@usinternet.com> wrote in message > news:%23NUE7Nl9JHA.1252@TK2MSFTNGP04.phx.gbl... >> >> "Al Reid" <arei***@reidDASHhome.com> wrote >> >>> If there was an error in the logging code it would be raided to the >>> caller >>> and handled there. I'm 99.99% sure that there isn't a problem in the >>> logger >>> class. >> >> Ok, I can only take that at face value, you know the code better.... >> > > I con provide the code if you want to see it. When I inherited the code > it used FSO and only flushed to disk when the program closed. Not really > useful if the program crashed and burned. I removed the FSO and replaced > it with native VB file handling and the file is opened, written and closed > on each call to LogEvent. > >>> >>> If I start a scan again after the problem the info is written to the log >>> on >>> the subsequent run without re-initializing the log class. Much of the >>> logging was added after the problem was discovered. I suppose I could >>> replace the logging with message boxes, but I'm not sure this would >>> change >>> anything. >> >> If at all possible, I'd rather log timestamps and milestones during >> the assembly process. If you find out exactly where it skips out, or >> if it skips out in different places, it might give you a clue where else >> to >> look.... >> >> LFS >> > > Larry, > > I have all of that and it is turned on by starting the application with a > /D command line switch and writes to a separate debug log file. It has > never failed while debug logging is turned on. That is what is making > this so hard to solve. Give me a repeatable problem and I can solve it in > minutes. This intermittent problem that seems to defy logic is driving me > crazy. > > Debug logging also has a noticeable impact on the performance of the > application. A single scan batch can create over 5000 log entries. Maybe > I have too many log calls, but I tried to log everything that was going on > (page retrieved, barcode detected, created batch folder, created document > folder, move page, delete blank page, etc.) > > -- > Al Reid > > routine. I'm going to run it with debug turned on again today and see it I get lucky and catch one. -- Al Reid
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> skrev i meddelandet A MsgBox just before leaving Assembly, to be sure it leaves "the right way"?news:eV9R3zk9JHA.2872@TK2MSFTNGP05.phx.gbl... > "Larry Serflaten" <serfla***@usinternet.com> wrote in message > news:%231Hmuvf9JHA.3544@TK2MSFTNGP04.phx.gbl... >> >> "Al Reid" <ar***@reidDASHhome.com> wrote >> >>> > Since no errors rised, my quarter is on the job is somehow reported as >>> > finished even though it's not. >>> >>> I have the following in the calling procedure (Scan_Done event): >>> >>> goLogger.LogEvent "Off to Assembly" >>> call Assembly(oWorkArray) >>> goLogger.LogEvent "Back from Assembly" >>> >>> The "Off to Assembly" in logged to the file but the "Back from Assembly" >>> is >>> not. If the assembly procedure thought it was done it would return back >>> to >>> the caller. It does not. If there was an error thrown in the assembly >>> procedure it would be logged by the error handler then return to the >>> event >>> procedure and log the return message. There are also other logging >>> statements in the code that are written to the file after a successful >>> return from assembly. Nothing is logged after going to Assembly, it >>> just >>> ends up in the form idle message loop waiting for user input. >>> >>> Got any more quarters to spend? :o) >> >> >> What would happen if there was an error in your logger routines? >> Like, something preventing the log to be written. That would help >> explain why you don't see log entries as you expect.... >> >> LFS >> > > Larry, > > If there was an error in the logging code it would be raided to the caller > and handled there. I'm 99.99% sure that there isn't a problem in the > logger class. I've been using it for over 9 years in countless > applications and have never had a problem with it anywhere else. Yes, I > agree that it's usually a simple explanation, but I don't think this is > it. > > If I start a scan again after the problem the info is written to the log > on the subsequent run without re-initializing the log class. Much of the > logging was added after the problem was discovered. I suppose I could > replace the logging with message boxes, but I'm not sure this would change > anything. > > -- > Al Reid > > /Henning Hi Al,
Show quoteHide quote "Al Reid" <ar***@reidDASHhome.com> wrote in message Put an On Error GoTo in the calling block/procedure. And double check that news:u3wgGQf9JHA.5780@TK2MSFTNGP03.phx.gbl... > > I have the following in the calling procedure (Scan_Done event): > > goLogger.LogEvent "Off to Assembly" > call Assembly(oWorkArray) > goLogger.LogEvent "Back from Assembly" > > The "Off to Assembly" in logged to the file but the "Back from Assembly" > is not. If the assembly procedure thought it was done it would return > back to the caller. It does not. If there was an error thrown in the > assembly procedure it would be logged by the error handler then return to > the event procedure and log the return message. There are also other > logging statements in the code that are written to the file after a > successful return from assembly. Nothing is logged after going to > Assembly, it just ends up in the form idle message loop waiting for user > input. > > Got any more quarters to spend? :o) > your goLogger.LogEvent, and whatever error logging you have elsewhere, is itself recovering if it encounters an error.
Show quote
Hide quote
"Bill McCarthy" <TPASoft.com Are Identity Thieves> wrote in message The logger class will log during the next scan without re-initializing the news:e7EZUJg9JHA.4168@TK2MSFTNGP05.phx.gbl... > Hi Al, > > "Al Reid" <ar***@reidDASHhome.com> wrote in message > news:u3wgGQf9JHA.5780@TK2MSFTNGP03.phx.gbl... >> >> I have the following in the calling procedure (Scan_Done event): >> >> goLogger.LogEvent "Off to Assembly" >> call Assembly(oWorkArray) >> goLogger.LogEvent "Back from Assembly" >> >> The "Off to Assembly" in logged to the file but the "Back from Assembly" >> is not. If the assembly procedure thought it was done it would return >> back to the caller. It does not. If there was an error thrown in the >> assembly procedure it would be logged by the error handler then return to >> the event procedure and log the return message. There are also other >> logging statements in the code that are written to the file after a >> successful return from assembly. Nothing is logged after going to >> Assembly, it just ends up in the form idle message loop waiting for user >> input. >> >> Got any more quarters to spend? :o) >> > > Put an On Error GoTo in the calling block/procedure. And double check that > your goLogger.LogEvent, and whatever error logging you have elsewhere, is > itself recovering if it encounters an error. logger class. When there are errors encountered, they are logged and handled correctly. Only this one problem things just quit, seemingly without returning back to the calling routines. Sure, I'll have a look at the logger class and I can even replace it with message boxes, but after looking at this problem for several years, I'm pretty sure it isn't in the logger. -- Al Reid "Al Reid" <ar***@reidDASHhome.com> schrieb im Newsbeitrag Are there any DoEvents there in your code - especiallynews:u3wgGQf9JHA.5780@TK2MSFTNGP03.phx.gbl... > I have the following in the calling procedure (Scan_Done event): > > goLogger.LogEvent "Off to Assembly" > call Assembly(oWorkArray) > goLogger.LogEvent "Back from Assembly" inside that SubRoutine-Stack, you enter with call Assembly? If you are dealing with Batch-Processes there - how is the waiting for these processes (to be finished) ensured? Olaf
Show quote
Hide quote
"Schmidt" <s**@online.de> wrote in message Olaf,news:eXUc%23Al9JHA.1488@TK2MSFTNGP03.phx.gbl... > > "Al Reid" <ar***@reidDASHhome.com> schrieb im Newsbeitrag > news:u3wgGQf9JHA.5780@TK2MSFTNGP03.phx.gbl... > >> I have the following in the calling procedure (Scan_Done event): >> >> goLogger.LogEvent "Off to Assembly" >> call Assembly(oWorkArray) >> goLogger.LogEvent "Back from Assembly" > > Are there any DoEvents there in your code - especially > inside that SubRoutine-Stack, you enter with call Assembly? > > If you are dealing with Batch-Processes there - how is the > waiting for these processes (to be finished) ensured? > > Olaf > There are no DoEvents() in either the Assembly procedure or in the DLL. I'm not sure what your question is about batches. The batch processing is not shelling out to a batch file or running batch commands. It is the processing of a stack of paper that is arranged as one or more batches. Each batch contains documents and each document contains pages. Scanned pages may contain barcodes that indicate start of batch, start of document or other information used in indexing the document. The scanned images are processed to 1) detect barcodes 2) detect blank pages and 3) to separate the stack of pages into batches, and documents based on the detected barcodes. The process is all done serially in VB code before another scan can be started. -- Al Reid Are you using Dir() function by any chance? It keeps a handle open to the
folder(See FindFirstFile), so other programs perhaps can't delete the folder, or rename it. "Nobody" <nob***@nobody.com> wrote in message I am not using the Dir() function anywhere in the code related to scanning news:OMKz2Yg9JHA.4944@TK2MSFTNGP02.phx.gbl... > Are you using Dir() function by any chance? It keeps a handle open to the > folder(See FindFirstFile), so other programs perhaps can't delete the > folder, or rename it. > or error logging. All of the file handling is done in a DLL that is shared by all of the applications that access the scan repository. The batches are not visible to the next step in the process untill scan and assembly have been completed. The DLL does not use DIR() at all. Files are either created by the scan OCX or moved, copied or deleted by the DLL. The scan sw processed thousands of pages per day and this thing hits randomly. Some days it never happens or it doesn't happen for weeks then it may happen once or twice a day then disappear again. -- Al Reid "Al Reid" <arei***@reidDASHhome.com> wrote in message This might happen if you have DoEvents, but you said you don't have it in a news:eiua4Rc9JHA.4204@TK2MSFTNGP04.phx.gbl... > The short description is that some error or event occurs that causes the > call stack to unwind without any logging or raising an error or returning > to the called procedures. area that is related to the problem; however, some things that are done to controls can trigger events, and if these events or the functions that they call; call DoEvents, then you have a problem. Try wrapping DoEvents() in UseDoEvents() sub, and in that sub, increment/decrement a global counter variable and check it in certain functions. Also, perhaps some component did something that is equivalent to DoEvents. This is possible to do from any language including C++. To find out if this is the case, add a static counter variable. Example: Sub SomeSub() Static lReentrancyCounter As Long lReentrancyCounter = lReentrancyCounter + 1 If lReentrancyCounter >= 2 Then MsgBox "Reentrancy error in SomeSub" End If ' Some code ExitSub: lReentrancyCounter = lReentrancyCounter - 1 ErrorHandler: ' Some code Resume ExitSub ' Must ensure that lReentrancyCounter is decremented End Sub Add that to some routines that are most likely to interfere with the assembly process if a hypothetical DoEvents was used. Below is a link on how to make DoEvents in C++: http://www.codeguru.com/forum/showpost.php?p=595814&postcount=3 Finally, try using the performance counters in the Control Panel to log memory usage. Some applications misbehave when the memory is low.
Show quote
Hide quote
"Nobody" <nob***@nobody.com> wrote in message I suppose I could try that. Once the scan is complete and processing news:ekc2f7m9JHA.5780@TK2MSFTNGP03.phx.gbl... > "Al Reid" <arei***@reidDASHhome.com> wrote in message > news:eiua4Rc9JHA.4204@TK2MSFTNGP04.phx.gbl... >> The short description is that some error or event occurs that causes the >> call stack to unwind without any logging or raising an error or returning >> to the called procedures. > > This might happen if you have DoEvents, but you said you don't have it in > a area that is related to the problem; however, some things that are done > to controls can trigger events, and if these events or the functions that > they call; call DoEvents, then you have a problem. Try wrapping DoEvents() > in UseDoEvents() sub, and in that sub, increment/decrement a global > counter variable and check it in certain functions. > > Also, perhaps some component did something that is equivalent to DoEvents. > This is possible to do from any language including C++. To find out if > this is the case, add a static counter variable. Example: > > Sub SomeSub() > Static lReentrancyCounter As Long > > lReentrancyCounter = lReentrancyCounter + 1 > If lReentrancyCounter >= 2 Then > MsgBox "Reentrancy error in SomeSub" > End If > > ' Some code > > ExitSub: > lReentrancyCounter = lReentrancyCounter - 1 > ErrorHandler: > ' Some code > Resume ExitSub ' Must ensure that lReentrancyCounter is decremented > End Sub > > > Add that to some routines that are most likely to interfere with the > assembly process if a hypothetical DoEvents was used. Below is a link on > how to make DoEvents in C++: > > http://www.codeguru.com/forum/showpost.php?p=595814&postcount=3 > > Finally, try using the performance counters in the Control Panel to log > memory usage. Some applications misbehave when the memory is low. > > begins, all controls on the form are disabled and no other events should be raised (events are only raised by the scanner OCX/ActiveX Exe and form controls) and therefore, no other DoEvents should be called. I'm not ruling this out and I'll give it a try. We just finished scanning about 2/3 of the days volume with the debug logging turned on. By this time yesterday there were 3 hits. So far today there were none. This has been the case anytime we run with debug logging enabled. Al Also, are you doing any subclassing? If so, which object?
Can you post the WindowProc() code, or at least what messages you are handling. "Nobody" <nob***@nobody.com> wrote in message There is no subclassing in this application and, therefore, no WindowProc() news:uuYCg7m9JHA.5780@TK2MSFTNGP03.phx.gbl... > Also, are you doing any subclassing? If so, which object? > > Can you post the WindowProc() code, or at least what messages you are > handling. > > code. -- Al Reid "Al Reid" <arei***@reidDASHhome.com> wrote I've been following this thread, I just used this message to reply to, with an> If anyone has any ideas, troubleshooting suggestions or even off-the-wall > suggestions I would welcome hearing them. I can provide more info to anyone > that is willing to lend a hand. off-the-wall idea you might try. What if you altered your logger to queue log messages instead of writing them to disk. Before you go to 'assembly' you could clear the queue (a Collection object) and when you get back from the 'assembly' call you could check the last entry in the queue to be what you expect. If it is what you expect, you really don't need to write that whole queue to disk. If it is not what you expect, you would then want to write at least the last few entries to see where it stopped. That way you only log the unexpected returns. Since the logger is in a class, you could also have it flush the queue to disk when the class is terminated. Or, if possible, you could provide a way for the user to cause the queue to be flushed to disk. Then you could leave that running until you see it quit processing the documents (the error happens) then you could have the user shut down the app or, if provided, have the user flush the queue to disk. This is just a way to narrow down the contents of the log (and avoid file I/O) until there is some abnormality with the process. Queueing the messages should not be a significant delay to your assembly process such that you can leave it on for weeks at a time under normal working conditions, without impacting the user too much.... LFS
Show quote
Hide quote
"Larry Serflaten" <serfla***@usinternet.com> wrote in message Larry,news:eiZ$ZEn9JHA.2872@TK2MSFTNGP05.phx.gbl... > > "Al Reid" <arei***@reidDASHhome.com> wrote > >> If anyone has any ideas, troubleshooting suggestions or even off-the-wall >> suggestions I would welcome hearing them. I can provide more info to >> anyone >> that is willing to lend a hand. > > I've been following this thread, I just used this message to reply to, > with an > off-the-wall idea you might try. > > What if you altered your logger to queue log messages instead of writing > them > to disk. Before you go to 'assembly' you could clear the queue (a > Collection object) > and when you get back from the 'assembly' call you could check the last > entry in the > queue to be what you expect. If it is what you expect, you really don't > need to write > that whole queue to disk. If it is not what you expect, you would then > want to write > at least the last few entries to see where it stopped. That way you only > log the > unexpected returns. > > Since the logger is in a class, you could also have it flush the queue to > disk when > the class is terminated. Or, if possible, you could provide a way for the > user to > cause the queue to be flushed to disk. > > Then you could leave that running until you see it quit processing the > documents > (the error happens) then you could have the user shut down the app or, if > provided, > have the user flush the queue to disk. > > This is just a way to narrow down the contents of the log (and avoid file > I/O) until > there is some abnormality with the process. Queueing the messages should > not be > a significant delay to your assembly process such that you can leave it on > for weeks > at a time under normal working conditions, without impacting the user too > much.... > > LFS I think that would be a good suggestion and, maybe, worth a try. My fear with this approach is that if the app continues to behave as is does not, I would never get back to the line following the call to Assembly to look at the queue. I would be sitting in the form idle loop and queue checking would never be performed. Now, I suppose I could add a command button to the form to do the queue checking after the problem occurred. I ran with the logging enabled today and, of course, had no problems so far. The logging isn't having as significant an effect on this current PC as I saw in the past, so I think I'll just leave it enabled and see what happens. I'll rename the file each morning to keep the size down and just wait. -- Al
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> wrote But if the user notices that the job did not finish, the user could initiate> > Then you could leave that running until you see it quit processing the > > documents > > (the error happens) then you could have the user shut down the app or, if > > provided, > > have the user flush the queue to disk. > > > > I think that would be a good suggestion and, maybe, worth a try. My fear > with this approach is that if the app continues to behave as is does not, I > would never get back to the line following the call to Assembly to look at > the queue. I would be sitting in the form idle loop and queue checking > would never be performed. a queue flush (either shut-down, or command button, whatever). > Now, I suppose I could add a command button to the form to do the queue You would really just have the button flush the queue if there is anything in it.> checking after the problem occurred. If, when you get back from the Assembly call and find the last entry as you expect, you could clear the queue at that time also. Since it acted correctly, there wold be nothing to log, But when the user notices the job did not finish, that's when you want them to flush the queue to disk. If the queue is empty, then it returned as expected and it must have been the system that did not do what it was told, or, if there is stuff in the queue, then it acts as you indicate, it goes back to the form's input loop without returning from the Assembly call (properly). The main point is that the user needs to watch each job to see that it finishes correclty. If it does not, thats when they need to take action to flush the queue so you can see what the last items on the list were. You might make that queue specific to the assembly process, (your /D switch) so the log is not cluttered with normal operation entries.... LFS "Al Reid" <arei***@reidDASHhome.com> wrote In addition to checking the last entry, you might also want to test the number> > If it is what you expect, you really don't need to write > > that whole queue to disk. If it is not what you expect, you would then > > want to write at least the last few entries to see where it stopped. of entries in the queue just to be sure some areas did not get skipped.... LFS I have read most of the responses... Let's see the code for the Assembly and
all related code. -- Show quoteHide quoteRandem Systems Your Installation Specialist The Top Inno Setup Script Generator http://www.randem.com/innoscript.html Disk Read Error Press Ctl+Alt+Del to Restart http://www.randem.com/discus/messages/9402/9406.html?1236319938 "Al Reid" <arei***@reidDASHhome.com> wrote in message news:eiua4Rc9JHA.4204@TK2MSFTNGP04.phx.gbl... >I have a scanning application that I wrote back in the end of 2006. I was >written in VB6 with some API calls (SHCreateDirectory and SHFileOperation). >Since that time there has been an intermittent and impossible to find >problem that has haunted me. Sometimes it disappears for months only to >reappear and bite me again. > > I need your help because I'm the only developer and I have no one to > bounce ideas off of and I can think of no better group of people to turn > to for assistance. > > The short description is that some error or event occurs that causes the > call stack to unwind without any logging or raising an error or returning > to the called procedures. > > The application is used to scan batches of documents to tiff files. > Barcoded sheets are used to delineate batches and documents within a > batch. Paper is loaded into the scanner and the start scan button is > clicked. The button click event handler calls a routine that starts the > scan (handled by an ActiveX EXE that wraps the Kodak imgScan OCX) then > enters a loop looking for pages to display to the scan operator. The rest > is then handled by events raised by the ActiveX EXE . Once the scan is > complete, the Scan_Done event is raised and the processing of the scanned > images begins. A blank page detection procedure is called followed by a > barcode detection procedure. Up to this point everything is working > flawlessly. The next thing that happens is that the pages are moved into > batches and documents (Folders and sub-folders) based on the barcodes and > blank pages are deleted. This process is called "Assembly" and this is > where the problem occurs. Prior to calling assembly I log that it is going > to Assembly and I also log return from assembly. Occasionally, the > assembly process just quits and the application ends up in the form's > idle message loop doing nothing. All procedures have error handlers that > log errors. No handled or unhandled errors are logged, the return from > Assembly is not logged either. > > There is an ActiveX DLL that handles all of the folder creation, file > moving/deleting and database updates. > > Under what possible scenario can the application get several levels back > up the call stack without returning to the calling procedures. I suppose > if I was reading this I would say it's impossible, but somehow it's > happening. > > If anyone has any ideas, troubleshooting suggestions or even off-the-wall > suggestions I would welcome hearing them. I can provide more info to > anyone that is willing to lend a hand. > > -- > Al Reid > > I just had a quick look and you are asking for what could amount to over
1000 lines of code. Let me see if there isn't some way to reduce that to something more manageable. -- Show quoteHide quoteAl Reid "Randem" <newsgro***@randem.com> wrote in message news:ulxvKIo9JHA.5704@TK2MSFTNGP03.phx.gbl... >I have read most of the responses... Let's see the code for the Assembly >and all related code. > > -- > Randem Systems > Your Installation Specialist > The Top Inno Setup Script Generator > http://www.randem.com/innoscript.html > Disk Read Error Press Ctl+Alt+Del to Restart > http://www.randem.com/discus/messages/9402/9406.html?1236319938 > > > Is this a project you can email?
-- Show quoteHide quoteRandem Systems Your Installation Specialist The Top Inno Setup Script Generator http://www.randem.com/innoscript.html Disk Read Error Press Ctl+Alt+Del to Restart http://www.randem.com/discus/messages/9402/9406.html?1236319938 "Al Reid" <arei***@reidDASHhome.com> wrote in message news:eF%23hQWo9JHA.3964@TK2MSFTNGP04.phx.gbl... >I just had a quick look and you are asking for what could amount to over >1000 lines of code. Let me see if there isn't some way to reduce that to >something more manageable. > > -- > Al Reid > > > "Randem" <newsgro***@randem.com> wrote in message > news:ulxvKIo9JHA.5704@TK2MSFTNGP03.phx.gbl... >>I have read most of the responses... Let's see the code for the Assembly >>and all related code. >> >> -- >> Randem Systems >> Your Installation Specialist >> The Top Inno Setup Script Generator >> http://www.randem.com/innoscript.html >> Disk Read Error Press Ctl+Alt+Del to Restart >> http://www.randem.com/discus/messages/9402/9406.html?1236319938 >> >> >> > > How repeatable is the problem?
Have you attempted to isolate a set of input data which exhibits it, in order to narrow down the set of conditions causing it? Or have you already found that it's intermittent *even* with the exact same input data stream? Bob --
Show quote
Hide quote
"Bob O`Bob" <filter***@yahoogroups.com> wrote in message Bob,news:eJuYRlo9JHA.1248@TK2MSFTNGP04.phx.gbl... > How repeatable is the problem? > > Have you attempted to isolate a set of input data which exhibits it, > in order to narrow down the set of conditions causing it? > > Or have you already found that it's intermittent *even* with the > exact same input data stream? > > > > > Bob > -- It seems to be purely random. For example, you run a batch through the scanner and it fails. You then run the same batch through again, and, with the identical page count, it assembles properly. It randomly effects projects that use batch separators as well as those that do not. It randomly effects batches that are fixed page length as well as those that are variable and separate based on a barcode. I have never been able to find any input that will predictably cause the problem. In fact I have never been able to get it to fail while in the debugger or with debug logging enabled. Maybe I need to change jobs and leave it to the new guy :o) -- Al So, I have not read anything about doing the following.
Who says it is a VB6 problem? Log and monitor other applications that might be poping in and out like virus scanners etc. Log and monitor memory usage. If you run into virtual memory and have a bad disk, then ... Log and monitor disk I/O. I have an app that was flaky, but as soon as I sent output to a different disk, the problems all went away. Turns out that the manufacturer's disk test software said the disk was just fine. But I wrote a demanding disk I/O routine in VB6 and found that the disk had problems. It was an identical model to another in the PC but it ran very slowly. Probably many bad sectors. Gremlins, I am sure. Show quoteHide quote "Al Reid" wrote: > I have a scanning application that I wrote back in the end of 2006. I was > written in VB6 with some API calls (SHCreateDirectory and SHFileOperation). > Since that time there has been an intermittent and impossible to find > problem that has haunted me. Sometimes it disappears for months only to > reappear and bite me again. > > I need your help because I'm the only developer and I have no one to bounce > ideas off of and I can think of no better group of people to turn to for > assistance. > > The short description is that some error or event occurs that causes the > call stack to unwind without any logging or raising an error or returning to > the called procedures. > > The application is used to scan batches of documents to tiff files. > Barcoded sheets are used to delineate batches and documents within a batch. > Paper is loaded into the scanner and the start scan button is clicked. The > button click event handler calls a routine that starts the scan (handled by > an ActiveX EXE that wraps the Kodak imgScan OCX) then enters a loop looking > for pages to display to the scan operator. The rest is then handled by > events raised by the ActiveX EXE . Once the scan is complete, the Scan_Done > event is raised and the processing of the scanned images begins. A blank > page detection procedure is called followed by a barcode detection > procedure. Up to this point everything is working flawlessly. The next > thing that happens is that the pages are moved into batches and documents > (Folders and sub-folders) based on the barcodes and blank pages are deleted. > This process is called "Assembly" and this is where the problem occurs. > Prior to calling assembly I log that it is going to Assembly and I also log > return from assembly. Occasionally, the assembly process just quits and the > application ends up in the form's idle message loop doing nothing. All > procedures have error handlers that log errors. No handled or unhandled > errors are logged, the return from Assembly is not logged either. > > There is an ActiveX DLL that handles all of the folder creation, file > moving/deleting and database updates. > > Under what possible scenario can the application get several levels back up > the call stack without returning to the calling procedures. I suppose if I > was reading this I would say it's impossible, but somehow it's happening. > > If anyone has any ideas, troubleshooting suggestions or even off-the-wall > suggestions I would welcome hearing them. I can provide more info to anyone > that is willing to lend a hand. > > -- > Al Reid > > > For those that offered comments and suggestions, here is an update.
Yesterday, while running with debug logging enabled, it failed. The results of the combination of the normal logging along with the debug logging fails to shed any new light on the problem, but instead, keeps the mystery alive. One instance of the logger class is logging high level trace comments into a log file while a second instance is logging low level info to a separate file. When the problem struck, the debug log shows a call to the DLL being made from the Assembly procedure to delete a file and database info. The return is not logged in the debug log and the other log file similarly ends without logging the return from the assembly procedure. After the failure, I found that the file had been deleted along with the associated database records. It was mentioned earlier that the problem could be related to the logging class, but, with both instances failing to log at the same instant, I have to rule that out. I'm continuing to run with debug logging enabled in an attempt to collect more data and see if any patterns emerge. -- Al Reid Here is something that may help you RSTools
http://www.randem.com/rstools.html it can help you trace your app. -- Show quoteHide quoteRandem Systems Your Installation Specialist The Top Inno Setup Script Generator http://www.randem.com/innoscript.html Disk Read Error Press Ctl+Alt+Del to Restart http://www.randem.com/discus/messages/9402/9406.html?1236319938 "Al Reid" <arei***@reidDASHhome.com> wrote in message news:eQXu$tZ%23JHA.1248@TK2MSFTNGP04.phx.gbl... > For those that offered comments and suggestions, here is an update. > > Yesterday, while running with debug logging enabled, it failed. The > results of the combination of the normal logging along with the debug > logging fails to shed any new light on the problem, but instead, keeps the > mystery alive. One instance of the logger class is logging high level > trace comments into a log file while a second instance is logging low > level info to a separate file. When the problem struck, the debug log > shows a call to the DLL being made from the Assembly procedure to delete a > file and database info. The return is not logged in the debug log and the > other log file similarly ends without logging the return from the assembly > procedure. After the failure, I found that the file had been deleted > along with the associated database records. > > It was mentioned earlier that the problem could be related to the logging > class, but, with both instances failing to log at the same instant, I have > to rule that out. > > I'm continuing to run with debug logging enabled in an attempt to collect > more data and see if any patterns emerge. > > -- > Al Reid > > Thanks, I'll have a look at it.
-- Show quoteHide quoteAl Reid "Randem" <newsgro***@randem.com> wrote in message news:%23LIadBc%23JHA.4432@TK2MSFTNGP05.phx.gbl... > Here is something that may help you RSTools > http://www.randem.com/rstools.html it can help you trace your app. > > -- > Randem Systems > Your Installation Specialist > The Top Inno Setup Script Generator > http://www.randem.com/innoscript.html > Disk Read Error Press Ctl+Alt+Del to Restart > http://www.randem.com/discus/messages/9402/9406.html?1236319938 >
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> skrev i meddelandet I would think the other way around, the issue has narrowed down to two news:eQXu$tZ%23JHA.1248@TK2MSFTNGP04.phx.gbl... > For those that offered comments and suggestions, here is an update. > > Yesterday, while running with debug logging enabled, it failed. The > results of the combination of the normal logging along with the debug > logging fails to shed any new light on the problem, but instead, keeps the > mystery alive. One instance of the logger class is logging high level > trace comments into a log file while a second instance is logging low > level info to a separate file. When the problem struck, the debug log > shows a call to the DLL being made from the Assembly procedure to delete a > file and database info. The return is not logged in the debug log and the > other log file similarly ends without logging the return from the assembly > procedure. After the failure, I found that the file had been deleted > along with the associated database records. > > It was mentioned earlier that the problem could be related to the logging > class, but, with both instances failing to log at the same instant, I have > to rule that out. > > I'm continuing to run with debug logging enabled in an attempt to collect > more data and see if any patterns emerge. > > -- > Al Reid > > possible causes. The LogClass and/or the DLL. /Henning "Henning" <computer_h***@coldmail.com> wrote in message I think it's pretty safe to rule out the log class as it is working news:efxZlOi$JHA.4168@TK2MSFTNGP05.phx.gbl... > > > I would think the other way around, the issue has narrowed down to two > possible causes. > The LogClass and/or the DLL. > > /Henning > > flawlessly in many other applications and the chances of two instances that are writing to different log files failing simultaneously and causing the application to quit unexpectedly is unlikely. Keep in mind that the behavior of the application was identical before ANY debug logging was added to the application. Also, logging will continue on the next scan without restarting the application. Assuming that the DLL is the problem, what is the failure that could cause the application to return to the idle loop without returning via the called procedures? Al
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> skrev i meddelandet Does it log the return to the idle loop?news:OpihKEj$JHA.2120@TK2MSFTNGP02.phx.gbl... > "Henning" <computer_h***@coldmail.com> wrote in message > news:efxZlOi$JHA.4168@TK2MSFTNGP05.phx.gbl... >> >> >> I would think the other way around, the issue has narrowed down to two >> possible causes. >> The LogClass and/or the DLL. >> >> /Henning >> >> > > I think it's pretty safe to rule out the log class as it is working > flawlessly in many other applications and the chances of two instances > that are writing to different log files failing simultaneously and causing > the application to quit unexpectedly is unlikely. Keep in mind that the > behavior of the application was identical before ANY debug logging was > added to the application. Also, logging will continue on the next scan > without restarting the application. > > Assuming that the DLL is the problem, what is the failure that could cause > the application to return to the idle loop without returning via the > called procedures? > > Al > Is the app unexpectedly restarted? A stack manipulating error in the DLL? Some timing issue blocking the logging? Trace the flow checked by a global var set in the routines: StartJob var = var + 1 NextRoutine var = var + 1 NextNext var = var + 1 Ret from NextNext var = var -1 Ret from NextRoutine var = var -1 In the Idle loop break if var <> 0, if it never breaks the returnpath is followed. If var <> 0 Then MsgBox "Returpath broken, var = " & var End If ..... /Henning > Does it log the return to the idle loop? The exit from the scan wait loop is logged. However, at the point of failure the return from the assemblu routine is not logged (both of these are from one instance of the logger class). The detailed debug logger just ends after the call to the DLL to delete a file and database entries. > Is the app unexpectedly restarted? No, it is not. The scan form is called from the main form. The state of the scan form is as it was when the scan started (i.e. combo selections, buttons enabled, etc.) > A stack manipulating error in the DLL? The DLL was written in VB6 so any stack manipulation is via VB native runtime. > Some timing issue blocking the logging? I can't see how logging can be related to this issue since the initial problem occurred before logging was added to troubleshoot the problem and the behavior is the same with or without the logging. Show quoteHide quote > Trace the flow checked by a global var set in the routines: I can/will do this. I'm fairly certain of the outcome :o)> StartJob var = var + 1 > NextRoutine var = var + 1 > NextNext var = var + 1 > Ret from NextNext var = var -1 > Ret from NextRoutine var = var -1 > > In the Idle loop break if var <> 0, if it never breaks the returnpath is > followed. > If var <> 0 Then > MsgBox "Returpath broken, var = " & var > End If > .... > > /Henning -- Al Reid For one possibility, see this thread:
http://groups.google.com/group/microsoft.public.vb.bugs/browse_thread/thread/69b57048bbf4beda/8eda45caf0f8863b When the anomaly described above happens, the program sort of reboots itself, all Public variables are re-initialized to 0, but Main() is not reexecuted, however Form_Load maybe reexexuted. So to detect if this happening in your case, in the app main form that stays visible all the time, add the following MsgBox: MsgBox "Form_Load is called on " & Now So normally you would see this message once, but if the problem happens, you will see it more than once.
Show quote
Hide quote
"Nobody" <nob***@nobody.com> wrote in message I had a look at this and I'm having trouble seeing how it could apply. I news:eGbM$El$JHA.5092@TK2MSFTNGP03.phx.gbl... > For one possibility, see this thread: > > http://groups.google.com/group/microsoft.public.vb.bugs/browse_thread/thread/69b57048bbf4beda/8eda45caf0f8863b > > When the anomaly described above happens, the program sort of reboots > itself, all Public variables are re-initialized to 0, but Main() is not > reexecuted, however Form_Load maybe reexexuted. So to detect if this > happening in your case, in the app main form that stays visible all the > time, add the following MsgBox: > > MsgBox "Form_Load is called on " & Now > > So normally you would see this message once, but if the problem happens, > you will see it more than once. > don't have and CreateWindowEx() calls or a WindowProc() in my application. Forms are created and displayed using frm.Show and the current form has need shown from the main form. The state of the form (combo box selections, radio buttons, controls enabled/disabled) are as they were just before the problem hits. -- Al Reid
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> wrote in message When logging is on, are there are particular points or general occurance ofnews:eiua4Rc9JHA.4204@TK2MSFTNGP04.phx.gbl... > I have a scanning application that I wrote back in the end of 2006. I was > written in VB6 with some API calls (SHCreateDirectory and SHFileOperation). > Since that time there has been an intermittent and impossible to find > problem that has haunted me. Sometimes it disappears for months only to > reappear and bite me again. > > I need your help because I'm the only developer and I have no one to bounce > ideas off of and I can think of no better group of people to turn to for > assistance. > > The short description is that some error or event occurs that causes the > call stack to unwind without any logging or raising an error or returning to > the called procedures. > > The application is used to scan batches of documents to tiff files. > Barcoded sheets are used to delineate batches and documents within a batch. > Paper is loaded into the scanner and the start scan button is clicked. The > button click event handler calls a routine that starts the scan (handled by > an ActiveX EXE that wraps the Kodak imgScan OCX) then enters a loop looking > for pages to display to the scan operator. The rest is then handled by > events raised by the ActiveX EXE . Once the scan is complete, the Scan_Done > event is raised and the processing of the scanned images begins. A blank > page detection procedure is called followed by a barcode detection > procedure. Up to this point everything is working flawlessly. The next > thing that happens is that the pages are moved into batches and documents > (Folders and sub-folders) based on the barcodes and blank pages are deleted. > This process is called "Assembly" and this is where the problem occurs. > Prior to calling assembly I log that it is going to Assembly and I also log > return from assembly. Occasionally, the assembly process just quits and the > application ends up in the form's idle message loop doing nothing. All > procedures have error handlers that log errors. No handled or unhandled > errors are logged, the return from Assembly is not logged either. > > There is an ActiveX DLL that handles all of the folder creation, file > moving/deleting and database updates. > > Under what possible scenario can the application get several levels back up > the call stack without returning to the calling procedures. I suppose if I > was reading this I would say it's impossible, but somehow it's happening. > > If anyone has any ideas, troubleshooting suggestions or even off-the-wall > suggestions I would welcome hearing them. I can provide more info to anyone > that is willing to lend a hand. > code that would close, re-open, re-set, re-use, ... file handles; where as without logging no such code runs or happens infrequently? Who has initial and then final ownership of file handles? the exe or dll? -ralph "Ralph" <nt_consultin***@yahoo.com> wrote in message In the code that is related to scanning there are no other VB file handling news:uCGoPJn$JHA.5068@TK2MSFTNGP03.phx.gbl... > > > When logging is on, are there are particular points or general occurance > of > code that would close, re-open, re-set, re-use, ... file handles; where as > without logging no such code runs or happens infrequently? > > Who has initial and then final ownership of file handles? the exe or dll? > > -ralph code sections. The Tiff files are created and written by the scanning OCX and files are created/moved/deleted using API calls. The logger is the only thing using VB file handles. The DLL does not have any logging code in it and does not share file handles. Also, the problem started before I added trace logging to the error handler and a separate debug logger. Al "Al Reid" <arei***@reidDASHhome.com> wrote I thought it strange to see your logger leave the file open until it is written to,> Also, the problem started before I added trace logging to the error handler > and a separate debug logger. and then close and re-open it for every entry. That is not how I learned file I/O. Get in and get out, was always my method of choice.... FWIW Did you know that Close does not write the buffer data to disk? Check VB help. Look at what it says for Close, and then what it says for Reset.... (A slight, but perhaps significant, difference). No help on your problem though. It certainly looks like something that will need to be watched very closely. The only suggestion I could think of was to add more debug (log) lines until you identify at which line the log quits and go from there.... Good luck! LFS
Show quote
Hide quote
"Larry Serflaten" <serfla***@usinternet.com> wrote in message I guess it ended up that way when I did a quick conversion from FSO to VB news:eMZcqKw$JHA.4432@TK2MSFTNGP05.phx.gbl... > > "Al Reid" <arei***@reidDASHhome.com> wrote > >> Also, the problem started before I added trace logging to the error >> handler >> and a separate debug logger. > > I thought it strange to see your logger leave the file open until it is > written to, > and then close and re-open it for every entry. That is not how I learned > file I/O. Get in and get out, was always my method of choice.... > > FWIW Did you know that Close does not write the buffer data to disk? > Check VB help. Look at what it says for Close, and then what it says > for Reset.... (A slight, but perhaps significant, difference). > > No help on your problem though. It certainly looks like something > that will need to be watched very closely. > > The only suggestion I could think of was to add more debug (log) lines > until you identify at which line the log quits and go from there.... > > Good luck! > LFS > file handling many years ago. As I was getting ready to post it I saw that and, although I don't think it is a problem, thought I should swap it around. So far, after changing the logger it seems that I have never lost a line of logging due to an app crash. However, if the PC crashed I may loose the last entry, I think. The only place left to add logging is in the DLL since I am logging the calls and returns and it gets lost in the DLL, it appears. Thanks, Larry. -- Al Reid Could you post your super-duper log routine? Many think it could be the
cause however unlikely, but unless you post it, posters will keep asking about it. "Nobody" <nob***@nobody.com> wrote in message I can do that when I get back to the office tomorrow.news:e4W6FRn$JHA.4692@TK2MSFTNGP02.phx.gbl... > Could you post your super-duper log routine? Many think it could be the > cause however unlikely, but unless you post it, posters will keep asking > about it. > One point of clarification. The problem initially existed prior to adding the debug logging to the application. That is why I really don't think that the logger has anything to do with the problem. I added another instance of the logger class to do additional detailed debug logging and both instances fail lo log at the same time, although logging to separate files. All of this together leads me away from the logger as being related to the problem. One thing I have found, after two failures with logging turned on, is that the call to the dll that failed both times was deleting files and database entries. This is consistent with what I had observed prior to debug logging. The deletes are done using API calls (SHFileOperations, I believe, but I don't have the code in front of me). -- Al Reid "Nobody" <nob***@nobody.com> wrote in message OK, you asked for it. This logging code is something I inherited many years news:e4W6FRn$JHA.4692@TK2MSFTNGP02.phx.gbl... > Could you post your super-duper log routine? Many think it could be the > cause however unlikely, but unless you post it, posters will keep asking > about it. > ago. At the time, it was using the FSO and only closed and flushed the file when StopLogging was called. I revised it to use native VB file handling and to flush each line after it is written. No claim that this is a "super-duper log routine," but it is used in every app I have written in the last 7 years and it has never caused any problems. ============================================== Option Explicit Private Const ERR_CLOG_NOT_INITIALIZED = vbObjectError + 6300 Private Const ERR_CLOG_INIT_FAILED = vbObjectError + 6301 Private Const CLOG_NOT_INITIALIZED_MSG = "CLog Failed to Initialize the Log File" Private Const CLOG_INIT_FAILED_MSG = "CLog Failed to Initialize the Log File" Private mblnInitialized As Boolean Private mlngFileNum As Long Private mstrLogPath As String Public Sub StopLogging() If Not mblnInitialized Then Err.Raise ERR_CLOG_NOT_INITIALIZED, "CLog::LogEvent", CLOG_NOT_INITIALIZED_MSG Exit Sub End If CloseLog End Sub Public Sub LogEvent(LogEntry As String, Optional ByVal LogCode As Long = -1) Dim strLogMessage As String If Not mblnInitialized Then Err.Raise ERR_CLOG_NOT_INITIALIZED, "CLog::LogEvent", CLOG_NOT_INITIALIZED_MSG Exit Sub End If strLogMessage = Format$(Now, "yyyy/mm/dd Hh:Nn:Ss") & " - " & LogEntry & " " If LogCode <> -1 Then strLogMessage = strLogMessage & " - Error Code = " & LogCode End If WriteLine strLogMessage End Sub Public Sub StartLogging(LogPath As String) On Error GoTo ERROR_HANDLER mstrLogPath = LogPath OpenLog LogPath WriteLine vbNewLine & Format$(Now, "yyyy/mm/dd Hh:Nn:Ss") & " - Logger Started..." & vbNewLine mblnInitialized = True EXIT_HANDLER: Exit Sub ERROR_HANDLER: Err.Raise ERR_CLOG_INIT_FAILED, "CLog::StartLogging", CLOG_INIT_FAILED_MSG Resume EXIT_HANDLER Resume End Sub Public Sub LogComment(Comment As String) If Not mblnInitialized Then Err.Raise ERR_CLOG_NOT_INITIALIZED, "CLog::LogEvent", CLOG_NOT_INITIALIZED_MSG Exit Sub End If Dim strLogMessage As String strLogMessage = Space(22) & Comment WriteLine strLogMessage End Sub Private Function CloseLog() Close #mlngFileNum End Function Private Sub OpenLog(ByVal LogPath As String) mlngFileNum = FreeFile Open LogPath For Append As #mlngFileNum End Sub Private Sub WriteLine(ByVal Text As String) Print #mlngFileNum, Text Close #mlngFileNum OpenLog mstrLogPath End Sub ============================================== Also, let me reiterate that the problem I have been chasing for the last 2 years was occurring prior to adding any debug logging to the error log and adding the debug logging. -- Al Reid Then the only way to tackle the issue is for us to have the project and data
that causes the problem. I am sure I can find it. Is this request possible? -- Show quoteHide quoteRandem Systems Your Installation Specialist The Top Inno Setup Script Generator http://www.randem.com/innoscript.html Disk Read Error Press Ctl+Alt+Del to Restart http://www.randem.com/discus/messages/9402/9406.html?1236319938 "Al Reid" <arei***@reidDASHhome.com> wrote in message news:O0qW5av$JHA.4432@TK2MSFTNGP05.phx.gbl... > "Nobody" <nob***@nobody.com> wrote in message > news:e4W6FRn$JHA.4692@TK2MSFTNGP02.phx.gbl... >> Could you post your super-duper log routine? Many think it could be the >> cause however unlikely, but unless you post it, posters will keep asking >> about it. >> > > > OK, you asked for it. This logging code is something I inherited many > years ago. At the time, it was using the FSO and only closed and flushed > the file when StopLogging was called. I revised it to use native VB file > handling and to flush each line after it is written. No claim that this > is a "super-duper log routine," but it is used in every app I have written > in the last 7 years and it has never caused any problems. > > ============================================== > Option Explicit > > Private Const ERR_CLOG_NOT_INITIALIZED = vbObjectError + 6300 > Private Const ERR_CLOG_INIT_FAILED = vbObjectError + 6301 > > Private Const CLOG_NOT_INITIALIZED_MSG = "CLog Failed to Initialize the > Log File" > Private Const CLOG_INIT_FAILED_MSG = "CLog Failed to Initialize the Log > File" > > Private mblnInitialized As Boolean > Private mlngFileNum As Long > Private mstrLogPath As String > > Public Sub StopLogging() > > If Not mblnInitialized Then > Err.Raise ERR_CLOG_NOT_INITIALIZED, "CLog::LogEvent", > CLOG_NOT_INITIALIZED_MSG > Exit Sub > End If > > CloseLog > End Sub > > Public Sub LogEvent(LogEntry As String, Optional ByVal LogCode As Long > = -1) > Dim strLogMessage As String > > If Not mblnInitialized Then > Err.Raise ERR_CLOG_NOT_INITIALIZED, "CLog::LogEvent", > CLOG_NOT_INITIALIZED_MSG > Exit Sub > End If > > strLogMessage = Format$(Now, "yyyy/mm/dd Hh:Nn:Ss") & " - " & LogEntry & > " " > If LogCode <> -1 Then > strLogMessage = strLogMessage & " - Error Code = " & LogCode > End If > WriteLine strLogMessage > End Sub > > Public Sub StartLogging(LogPath As String) > > On Error GoTo ERROR_HANDLER > > mstrLogPath = LogPath > OpenLog LogPath > WriteLine vbNewLine & Format$(Now, "yyyy/mm/dd Hh:Nn:Ss") & " - Logger > Started..." & vbNewLine > mblnInitialized = True > > EXIT_HANDLER: > > Exit Sub > > ERROR_HANDLER: > Err.Raise ERR_CLOG_INIT_FAILED, "CLog::StartLogging", > CLOG_INIT_FAILED_MSG > Resume EXIT_HANDLER > Resume > > End Sub > > Public Sub LogComment(Comment As String) > If Not mblnInitialized Then > Err.Raise ERR_CLOG_NOT_INITIALIZED, "CLog::LogEvent", > CLOG_NOT_INITIALIZED_MSG > Exit Sub > End If > > Dim strLogMessage As String > strLogMessage = Space(22) & Comment > WriteLine strLogMessage > End Sub > > Private Function CloseLog() > > Close #mlngFileNum > > End Function > > Private Sub OpenLog(ByVal LogPath As String) > > mlngFileNum = FreeFile > Open LogPath For Append As #mlngFileNum > > End Sub > > Private Sub WriteLine(ByVal Text As String) > > Print #mlngFileNum, Text > Close #mlngFileNum > OpenLog mstrLogPath > > End Sub > > ============================================== > > Also, let me reiterate that the problem I have been chasing for the last 2 > years was occurring prior to adding any debug logging to the error log and > adding the debug logging. > > -- > Al Reid > >
Show quote
Hide quote
"Randem" <newsgro***@randem.com> wrote in message I appreciate your offer. It is a large project that includes a main news:eK6BW4v$JHA.4432@TK2MSFTNGP05.phx.gbl... > Then the only way to tackle the issue is for us to have the project and > data that causes the problem. I am sure I can find it. Is this request > possible? > > -- > Randem Systems > Your Installation Specialist > The Top Inno Setup Script Generator > http://www.randem.com/innoscript.html > Disk Read Error Press Ctl+Alt+Del to Restart > http://www.randem.com/discus/messages/9402/9406.html?1236319938 > application, an ActiveX Exe that wraps a 3rd party scanning OCX (wrapping done to make the scan component asynchronous), a custom DLL, 3rd party barcode reader and Oracle/File server. To complicate matters, there is no set of data that "causes" the problem. If I had a set of data that would repeatedly cause the problem it would have been solved by now. When it fails, I can manually e-run the file and data stream through the same code and it will assemble. Also, if I rescan the same batch of paper, it will not fail the second time. That has been the real issue with solving this issue. It seems to be purely random and not repeatable. Also, I have now experiences two failures with all debug logging turned on. Both times the failure occurred during a call to the DLL to delete a page and corresponding database entries. There is a debug log statement before and after the call to the DLL. The call to the DLL is logged, but the return is not. The error logger is logging the call and return from the Assembly routine. The call is logged, but the return is not. If the next failure occurs at the came DLL call I will change the code that deletes the file from SHFileOperations to either DeleteFile API or VB Kill function and see if this changes anything. Thanks, -- Al Reid Al Reid wrote:
.... > I appreciate your offer. It is a large project that includes a main This isn't completely clear (at least to me :) )...> application, an ActiveX Exe that wraps a 3rd party scanning OCX (wrapping > done to make the scan component asynchronous), a custom DLL, 3rd party > barcode reader and Oracle/File server. > .... > Also, I have now experiences two failures with all debug logging turned on. > Both times the failure occurred during a call to the DLL to delete a page > and corresponding database entries. There is a debug log statement before > and after the call to the DLL. The call to the DLL is logged, but the > return is not. The error logger is logging the call and return from the > Assembly routine. The call is logged, but the return is not. Is the DLL referred to above the VB DLL mentioned elsewhere or part of the 3rd party scanner code or Oracle API? Which is actually being logged and not is still unclear from the description above--which routine(s) does the last sentence refer to precisely? It would seem to me the most likely place for a symptom such as you describe of a return stack getting popped incorrectly would have to be in a non-pure-VB procedure. I could, in fact, see inside a C or assembler routine that used cdecl internally all it would take would be a mismatched argument list or similar. I would concentrate my efforts in these external routines; I think the VB runtime is well enough documented that faults therein are highly unlikely. I noted Larry's comment on the apparent difference between Close and Reset on buffering file output. If the app is closed normally after one of these failures if there were any pending system buffers as yet unwritten, the OS _should_ write them then. Any indication of this? I asked much earlier in thread but seen no response as to whether you've investigated updates of these components including firmware updates to the scanner itself. As noted, I think I'd be focusing on the interface to the other components, particularly looking for "sneak paths" of data-dependent routes that aren't taken normally but a failure to return a full data buffer from the scanner, say, could follow leading to some error branch instead of the normal branch and then a resulting "oops!--didn't intend _that_ to happen!" kind of thing. OBTW, just as a thought...you haven't turned off any of the safety options in the compiled .exe (like bounds checking, etc.) by any chance? Another ploy I like that on occasion is useful if there's a bug in the VB code is to disable all error handling and let the runtime bomb--sometimes its more informative than the way error handler was implemented. Also, try no optimization if have used speed/size optimization switch just in the outside case there's a problem there. Then there's the old bugaboo of a global aliased in a call list somewhere that could bite if turned that one off so compiler doesn't look for it. That one can lead to stack corruption, btw... -- "dpb" <n***@non.net> wrote in message There is an error logger and a debug logger. The call from the scan_done news:h2vlt0$fvv$1@news.eternal-september.org... > > This isn't completely clear (at least to me :) )... > > Is the DLL referred to above the VB DLL mentioned elsewhere or part of the > 3rd party scanner code or Oracle API? > > Which is actually being logged and not is still unclear from the > description above--which routine(s) does the last sentence refer to > precisely? event handler to the Assembly routine is surrounded by messages that get logged to the error log. Within the Assembly procedure each operation that calls out of the procedure is surrounded by messages that get logged to the degug log (assuming that the app has been started with the /D switch). So far it appears that when the glitch ocurrs the call to the DLL (orep.Contents.Remove(oPage.Name)) has been logged to the debug log, but the return is not logged and the return from the Assembly procedure to the scan_done event procedure is not logged to the error log either. > The DLL is a combination of mostly native VB with some API calls for > It would seem to me the most likely place for a symptom such as you > describe of a return stack getting popped incorrectly would have to be in > a non-pure-VB procedure. I could, in fact, see inside a C or assembler > routine that used cdecl internally all it would take would be a mismatched > argument list or similar. creating/deleting/moving files and folders. > I would concentrate my efforts in these external routines; I think the VB My current thought is to replace the SHFileOperations API call for deleting > runtime is well enough documented that faults therein are highly unlikely. the file with a VB Kill function. > I noted Larry's comment on the apparent difference between Close and Reset I have never had any indication of a problem withthe logger. Prior to > on buffering file output. If the app is closed normally after one of > these failures if there were any pending system buffers as yet unwritten, > the OS _should_ write them then. Any indication of this? replacing the FSO and open/closing with each write all error messages would get lost if the app crashed or so that was the appearance. That's why I changed it to use VB file handling and close/open, which as Larry correctly points out probably should be open/write/close. > I asked much earlier in thread but seen no response as to whether you've Sorry, I must have missed that. All of the scanner hardware/firmware and > investigated updates of these components including firmware updates to the > scanner itself. drivers are at the current revisions. At the point that the issue occurs the scanner is sitting idle and all that is running is code to assemble the scanned paper into batches and documents. > As noted, I think I'd be focusing on the interface to the other I agree with that, but at the time the error occurs, the scanner is sitting > components, particularly looking for "sneak paths" of data-dependent > routes that aren't taken normally but a failure to return a full data > buffer from the scanner, say, could follow leading to some error branch > instead of the normal branch and then a resulting "oops!--didn't intend > _that_ to happen!" kind of thing. idle and the working on moving the files to directories or deleting header sheets and blank pages. Images are not opened or operated on during this process. > OBTW, just as a thought...you haven't turned off any of the safety options Nope. I've never done that. I just checked and everything is unchecked in > in the compiled .exe (like bounds checking, etc.) by any chance? the app and all components. I have it compiling to native code. > Another ploy I like that on occasion is useful if there's a bug in the VB That's the way I have the code in the DLL where the error seems to be > code is to disable all error handling and let the runtime bomb--sometimes > its more informative than the way error handler was implemented. happening. I let the errors be thrown and handled in the app so I knoe what went wrong. I am logging errors in the app and taking any corrective action that may be appropriate. All other errors get properly logged and handled except fot this one where it seems that the error handles are never entered. > Also, try no optimization if have used speed/size optimization switch just I currently optimize for Fast code. I'll try recompiling the DLL and App > in the outside case there's a problem there. > for no optimization and see if anything changes. > Then there's the old bugaboo of a global aliased in a call list somewhere Can you expand on that point?> that could bite if turned that one off so compiler doesn't look for it. > That one can lead to stack corruption, btw... > > -- -- Al Reid "Al Reid" <arei***@reidDASHhome.com> wrote Compiling to P-code would be worth the effort as well, there are a few> > > I currently optimize for Fast code. I'll try recompiling the DLL and App > for no optimization and see if anything changes. things that happen differently, although its been too long a time for me to remember exactly what the differences were.... LFS
Show quote
Hide quote
"Larry Serflaten" <serfla***@usinternet.com> wrote in message Thanks, Larry. I'm adding that to the "Things to try" list.news:u85yN8x$JHA.1248@TK2MSFTNGP04.phx.gbl... > > "Al Reid" <arei***@reidDASHhome.com> wrote > >> > >> I currently optimize for Fast code. I'll try recompiling the DLL and App >> for no optimization and see if anything changes. > > Compiling to P-code would be worth the effort as well, there are a few > things that happen differently, although its been too long a time for me > to > remember exactly what the differences were.... > > LFS > -- Al Reid Al Reid wrote:
Show quoteHide quote > "dpb" <n***@non.net> wrote in message I'd wager if a stack is being popped incorrectly, it's somewhere in one > news:h2vlt0$fvv$1@news.eternal-september.org... .... >> Which is actually being logged and not is still unclear from the >> description above--which routine(s) does the last sentence refer to >> precisely? > > There is an error logger and a debug logger. The call from the scan_done > event handler to the Assembly routine is surrounded by messages that get > logged to the error log. Within the Assembly procedure each operation that > calls out of the procedure is surrounded by messages that get logged to the > degug log (assuming that the app has been started with the /D switch). > > So far it appears that when the glitch ocurrs the call to the DLL > (orep.Contents.Remove(oPage.Name)) has been logged to the debug log, but the > return is not logged and the return from the Assembly procedure to the > scan_done event procedure is not logged to the error log either. of these procedures, _not_ having to do w/ the file deletion itself. Are these event handlers your code or part of the 3rd party software support for the scanner? >> It would seem to me the most likely place for a symptom such as you Any use of an API removes you (as I'm sure you know; just emphasizing) >> describe of a return stack getting popped incorrectly would have to be in >> a non-pure-VB procedure. I could, in fact, see inside a C or assembler >> routine that used cdecl internally all it would take would be a mismatched >> argument list or similar. > > The DLL is a combination of mostly native VB with some API calls for > creating/deleting/moving files and folders. the VB protection and ability to check for stack alignment, number of arguments, etc., etc., ... I'd still be suspicious of a problem in a case where the scanner may not have done _quite_ the right thing and there's a problem that isn't being handled correctly. Just what that might be, of course, I have no clue w/o any more knowledge, it's just that the symptoms (at least as I think I hear) seem to be associated with a case where the document didn't get processed correctly by the rest of the app--that makes me think the document itself may not have gotten generated in pristine form which makes me wonder if there's not some extra or lacking piece of data flowing or not flowing around in these non-native portions of the code. >> I would concentrate my efforts in these external routines; I think the VB Maybe but I think it's deeper down than that...>> runtime is well enough documented that faults therein are highly unlikely. > > My current thought is to replace the SHFileOperations API call for deleting > the file with a VB Kill function. .... > ... I am logging errors in the app and taking any corrective action I'm suggesting that perhaps somewhere in the case of a problem what you > that may be appropriate. All other errors get properly logged and handled > except fot this one where it seems that the error handles are never entered. think is appropriate error handling/fixup just might not be so. If you ran for a while w/o any error trapping perhaps the runtime would barf differently than you expect... If you're not used the "assume no aliasing" compiler switch the problem mentioned before won't bite you. Let's not throw any more spurious things into the mix if you haven't used it... :) -- "dpb" <n***@non.net> wrote in message Some of both. The scan OCX, part of the Kodak Imaging professional (used to news:h2vv7q$ot6$1@news.eternal-september.org... > > I'd wager if a stack is being popped incorrectly, it's somewhere in one of > these procedures, _not_ having to do w/ the file deletion itself. > > Are these event handlers your code or part of the 3rd party software > support for the scanner? be the Wang Imaging components shipped with Windows pre XP), was not allowing the App to process other events or properly run the code that allows the scan operator to review every n pages scanned when instantiated directly in the application. This was a hard requirement that I could not change. To get around that I wrapped the scan OCX into and ActiveX EXE so I could get asynchronous operation. The events are raised by the OCX and are then raised back to the application by the ActiveX EXE. > Any use of an API removes you (as I'm sure you know; just emphasizing) the All valid suspicions. The Assembly routine is the third routine called in > VB protection and ability to check for stack alignment, number of > arguments, etc., etc., ... I'd still be suspicious of a problem in a case > where the scanner may not have done _quite_ the right thing and there's a > problem that isn't being handled correctly. Just what that might be, of > course, I have no clue w/o any more knowledge, it's just that the symptoms > (at least as I think I hear) seem to be associated with a case where the > document didn't get processed correctly by the rest of the app--that makes > me think the document itself may not have gotten generated in pristine > form which makes me wonder if there's not some extra or lacking piece of > data flowing or not flowing around in these non-native portions of the > code. > the Scan_Done event procedure. There are calls to a Barcode Detection procedure followed by a Blank Page Detection procedure. There are a few other minor calls as well, before the call to the Assembly routine. All three of these procedures loop through all of the pages in the batch and do some processing using the object model exposed by the DLL. The Barcode Detection procedure uses a 3rd party API and actually processes the data in each scanned TIF file. All three of these procedures log the call and returns to the error log file. The first two have never failed. All of that is to say that the call stack has been thoroughly exercised after the scan_done event is raised by the scanner and before the Assembly procedure is called. That is why I believe that the issue has to be somewhere in the Assembly procedure or the file/folder handling code of the DLL. > I just wish I could come up with a test cast that would reliably cause the > Maybe but I think it's deeper down than that... > code to fail. At this point it seems to be completely random and non repeatable. > True, but even if the error handling is not appropriate and given that I > I'm suggesting that perhaps somewhere in the case of a problem what you > think is appropriate error handling/fixup just might not be so. If you > ran for a while w/o any error trapping perhaps the runtime would barf > differently than you expect... have a pretty standard error handler, the error handler should be entered for any error that can be handled by VB. The entry to the error handler is logged as well as the exit from the procedure. Neither one gets logged when the error occurs. Errors that cannot be handled usually pop a message box and the app crashes. This is not happening. It just appears that the stack is being improperly popped. > If you're not used the "assume no aliasing" compiler switch the problem Thanks again for your input.> mentioned before won't bite you. Let's not throw any more spurious things > into the mix if you haven't used it... :) > > -- -- Al Reid
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> skrev i meddelandet It looks more and more to be som called routine popping off more than what news:es3uQZx$JHA.3320@TK2MSFTNGP04.phx.gbl... > "dpb" <n***@non.net> wrote in message > news:h2vlt0$fvv$1@news.eternal-september.org... >> >> This isn't completely clear (at least to me :) )... >> >> Is the DLL referred to above the VB DLL mentioned elsewhere or part of >> the 3rd party scanner code or Oracle API? >> >> Which is actually being logged and not is still unclear from the >> description above--which routine(s) does the last sentence refer to >> precisely? > > There is an error logger and a debug logger. The call from the scan_done > event handler to the Assembly routine is surrounded by messages that get > logged to the error log. Within the Assembly procedure each operation > that calls out of the procedure is surrounded by messages that get logged > to the degug log (assuming that the app has been started with the /D > switch). > > So far it appears that when the glitch ocurrs the call to the DLL > (orep.Contents.Remove(oPage.Name)) has been logged to the debug log, but > the return is not logged and the return from the Assembly procedure to the > scan_done event procedure is not logged to the error log either. > >> >> It would seem to me the most likely place for a symptom such as you >> describe of a return stack getting popped incorrectly would have to be in >> a non-pure-VB procedure. I could, in fact, see inside a C or assembler >> routine that used cdecl internally all it would take would be a >> mismatched argument list or similar. > > The DLL is a combination of mostly native VB with some API calls for > creating/deleting/moving files and folders. > >> I would concentrate my efforts in these external routines; I think the VB >> runtime is well enough documented that faults therein are highly >> unlikely. > > My current thought is to replace the SHFileOperations API call for > deleting the file with a VB Kill function. > >> I noted Larry's comment on the apparent difference between Close and >> Reset on buffering file output. If the app is closed normally after one >> of these failures if there were any pending system buffers as yet >> unwritten, the OS _should_ write them then. Any indication of this? > > I have never had any indication of a problem withthe logger. Prior to > replacing the FSO and open/closing with each write all error messages > would get lost if the app crashed or so that was the appearance. That's > why I changed it to use VB file handling and close/open, which as Larry > correctly points out probably should be open/write/close. > >> I asked much earlier in thread but seen no response as to whether you've >> investigated updates of these components including firmware updates to >> the scanner itself. > > Sorry, I must have missed that. All of the scanner hardware/firmware and > drivers are at the current revisions. At the point that the issue occurs > the scanner is sitting idle and all that is running is code to assemble > the scanned paper into batches and documents. > >> As noted, I think I'd be focusing on the interface to the other >> components, particularly looking for "sneak paths" of data-dependent >> routes that aren't taken normally but a failure to return a full data >> buffer from the scanner, say, could follow leading to some error branch >> instead of the normal branch and then a resulting "oops!--didn't intend >> _that_ to happen!" kind of thing. > > I agree with that, but at the time the error occurs, the scanner is > sitting idle and the working on moving the files to directories or > deleting header sheets and blank pages. Images are not opened or operated > on during this process. > >> OBTW, just as a thought...you haven't turned off any of the safety >> options in the compiled .exe (like bounds checking, etc.) by any chance? > > Nope. I've never done that. I just checked and everything is unchecked > in the app and all components. I have it compiling to native code. > >> Another ploy I like that on occasion is useful if there's a bug in the VB >> code is to disable all error handling and let the runtime bomb--sometimes >> its more informative than the way error handler was implemented. > > That's the way I have the code in the DLL where the error seems to be > happening. I let the errors be thrown and handled in the app so I knoe > what went wrong. I am logging errors in the app and taking any corrective > action that may be appropriate. All other errors get properly logged and > handled except fot this one where it seems that the error handles are > never entered. > >> Also, try no optimization if have used speed/size optimization switch >> just in the outside case there's a problem there. >> > I currently optimize for Fast code. I'll try recompiling the DLL and App > for no optimization and see if anything changes. > >> Then there's the old bugaboo of a global aliased in a call list somewhere >> that could bite if turned that one off so compiler doesn't look for it. >> That one can lead to stack corruption, btw... >> > > Can you expand on that point? >> -- > > -- > Al Reid > is pushed on the call stack. I'm not sure how optional parameters are treated, if wrongly detected as passed. /Henning "Henning" <computer_h***@coldmail.com> wrote in message That's been a suspicion of mine all along, but I have been unable to find a news:%236X6qky$JHA.3320@TK2MSFTNGP04.phx.gbl... > > It looks more and more to be som called routine popping off more than what > is pushed on the call stack. I'm not sure how optional parameters are > treated, if wrongly detected as passed. > > /Henning > way to track it down. So far it appears that the problem occurs in the DLL related to removing a page after it has been processed and needs to be discarded (i.e. a barcoded separator sheet). In this case, the file and associated database entries are deleted. Both of these appear to happen properly and without error, but the call to the DLL does not seem to return back to the calling routine. I really appreciate the input. As I've mentioned before, I'm the entire programming staff and have no one to bounce ideas off of. -- Al Reid Al Reid wrote:
.... > So far it appears that when the glitch ocurrs the call to the DLL I think I interpreted this wrongly earlier--you're meaning "Assembly > (orep.Contents.Remove(oPage.Name)) has been logged to the debug log, but the > return is not logged and the return from the Assembly procedure to the > scan_done event procedure is not logged to the error log either. procedure" as a functional description of the routine purpose, not a procedure written as an assembler handler, aren't you? If that's the case, it's somewhat harder to envision popping a stack incorrectly other than thru one of the APIs... .... > The DLL is a combination of mostly native VB with some API calls for ....which leads me to-- :)> creating/deleting/moving files and folders. > >> I would concentrate my efforts in these external routines; I think the VB >> runtime is well enough documented that faults therein are highly unlikely. > > My current thought is to replace the SHFileOperations API call for deleting > the file with a VB Kill function. I've never used the SHFileOperations API so I went and looked at it -- looks like a tremendous amount of overhead what w/ all those structures to fill, etc., as opposed to either simply the VB Kill statement or the Win32 DeleteFile API which simply takes a C-string file name. SO, after looking at it, I can envision quite a number of places for things to go wrong, one of the first/easiest of which is the necessity of having a _DOUBLY_ null-terminated string instead of simply a C-string (null terminated string). Also I note there's a hwnd handle to a dialog--that raises the specter of the previous note about a way to introduce an instability in VB and your adamant response there weren't any other windows handles--it ain't so clear that _might_ not somehow play now to me altho I'll admit my looking at the specifics of that was very superficial. Anyway, unless there was some very good reason for use SHFileOperations I'd ditch it on the general principle of parsimony--what's the point when there's a much simpler way? So, I'll say that change is one of the first I'd now recommend along w/ still looking _VERY_ closely at any and every API call; OS- or vendor-supplied. I'll tend to concur w/ the conclusion that since the symptoms were there before the error logging was added it's not likely the culprit. For error logging purposes I'd echo Larry's comments about OPEN/CLOSE as nearly atomically as you can get them simply to limit the likelihood of loss of data when an error does occur. AFAIR there isn't a way to force a FLUSH from VB other than the KILL which is a bludgeon-approach so CLOSE and counting on the OS is best practical answer unless go to low-level routines using all API calls w/ file handles instead of VB units. -- -- "dpb" <n***@non.net> wrote in message I'm sorry I wasn't clear on that. The "Assembly Procedure" is VB code that news:h307m8$khv$1@news.eternal-september.org... > Al Reid wrote: > ... >> So far it appears that when the glitch ocurrs the call to the DLL >> (orep.Contents.Remove(oPage.Name)) has been logged to the debug log, but >> the return is not logged and the return from the Assembly procedure to >> the scan_done event procedure is not logged to the error log either. > > I think I interpreted this wrongly earlier--you're meaning "Assembly > procedure" as a functional description of the routine purpose, not a > procedure written as an assembler handler, aren't you? logically assembles the pages into batches and documents based on rules and barcoded separator sheets. > If that's the case, it's somewhat harder to envision popping a stack I agree completely. The only non-VB code in that entire process are the API > incorrectly other than thru one of the APIs... File'Folder Handling calls. Show quoteHide quote > I guess that once you write it, it's no harder to use it than anything else.>> The DLL is a combination of mostly native VB with some API calls for >> creating/deleting/moving files and folders. >> >>> I would concentrate my efforts in these external routines; I think the >>> VB runtime is well enough documented that faults therein are highly >>> unlikely. >> >> My current thought is to replace the SHFileOperations API call for >> deleting the file with a VB Kill function. > > ...which leads me to-- :) > > I've never used the SHFileOperations API so I went and looked at it -- > looks like a tremendous amount of overhead what w/ all those structures to > fill, etc., as opposed to either simply the VB Kill statement or the Win32 > DeleteFile API which simply takes a C-string file name. > SO, after looking at it, I can envision quite a number of places for Again, one written and fully debugged, it should not be a problem. The > things to go wrong, one of the first/easiest of which is the necessity of > having a _DOUBLY_ null-terminated string instead of simply a C-string > (null terminated string). routine insures that the string is doubly null terminated. No reason I can see that it would fail in an unpredictable way every 5-10,000 usages. > Also I note there's a hwnd handle to a dialog--that raises the specter of The hWnd is always NULL and the FOF_SILENT and FOF_NOCONFIRMATION flags are > the previous note about a way to introduce an instability in VB and your > adamant response there weren't any other windows handles--it ain't so > clear that _might_ not somehow play now to me altho I'll admit my looking > at the specifics of that was very superficial. alwats set to prevent any dialogs from being shown. I have already mentioned that I will probably replace this with either a Kill or DeleteFile call. > Anyway, unless there was some very good reason for use SHFileOperations I'm sure there was a reason I did this back in 2006 when I wrote the code > I'd ditch it on the general principle of parsimony--what's the point when > there's a much simpler way? for the DLL. Honestly, I can't remember it right now. > So, I'll say that change is one of the first I'd now recommend along w/ Agreed.> still looking _VERY_ closely at any and every API call; OS- or > vendor-supplied. > I'll tend to concur w/ the conclusion that since the symptoms were there I plan to make and test that change. I just need to make one change at a > before the error logging was added it's not likely the culprit. For error > logging purposes I'd echo Larry's comments about OPEN/CLOSE as nearly > atomically as you can get them simply to limit the likelihood of loss of > data when an error does occur. AFAIR there isn't a way to force a FLUSH > from VB other than the KILL which is a bludgeon-approach so CLOSE and > counting on the OS is best practical answer unless go to low-level > routines using all API calls w/ file handles instead of VB units. > time and see how it effects the problem. I don't want to make more than one change at a time. This one is currently low priority and will be made after I solve the real issue. -- Al Reid "Al Reid" <arei***@reidDASHhome.com> wrote in message I just remembered the reason. In the object model the contents collection news:Oy7yu3z$JHA.4376@TK2MSFTNGP04.phx.gbl... >> Anyway, unless there was some very good reason for use SHFileOperations >> I'd ditch it on the general principle of parsimony--what's the point when >> there's a much simpler way? > > I'm sure there was a reason I did this back in 2006 when I wrote the code > for the DLL. Honestly, I can't remember it right now. > may contain both, either/or batches(folder), documents (folders) and pages (files) The same code can be used to perform either delete operation. This simplified the code and eliminated several tests in the logic. Seemed like a good idea at the time and when it works, it works well. I still don't know if this is the source of the problem or not. I will have to add logic to the routine to determine whether the object is a file or folder, then use the correct VB statement (Kill of RmDir) if I eliminate the SHFileOperation API call. I will also have to make sure the folder is empty if using RmDir. -- Al Reid Al Reid wrote:
> "dpb" <n***@non.net> wrote in message That would seem to be in the class of "in the eye of the beholder"... :).... > I guess that once you write it, it's no harder to use it than anything else. Just that there's a whole lot of extraneous stuff to be done to simply delete a file that there's a one-liner in native VB to do... >> SO, after looking at it, I can envision quite a number of places for Well, I'm back to the problem that _if_ something has gone wrong in the >> things to go wrong, one of the first/easiest of which is the necessity of >> having a _DOUBLY_ null-terminated string instead of simply a C-string >> (null terminated string). > > Again, one written and fully debugged, it should not be a problem. The > routine insures that the string is doubly null terminated. No reason I can > see that it would fail in an unpredictable way every 5-10,000 usages. process up to this point, it seems like a good place for that to appear unexpectedly. Has your unit-testing, etc., taken care of the edge cases--null file names, embedded blanks in unexpected places, wrong directory divider characer, any sort of other things a failed operation in one of these other vendor APIs might have done to trash the names or other pertinent data? It's not the expected that's happening here and assuming things are working or the data is the data you expect is a way to overlook where the problem may lay....expect something to have gone wrong (it almost surely has) and see where that leads instead. >> Also I note there's a hwnd handle to a dialog--that raises the specter of I understand the latter; earlier I thought it unlikely to be a problem, >> the previous note about a way to introduce an instability in VB and your >> adamant response there weren't any other windows handles--it ain't so >> clear that _might_ not somehow play now to me altho I'll admit my looking >> at the specifics of that was very superficial. > > The hWnd is always NULL and the FOF_SILENT and FOF_NOCONFIRMATION flags are > alwats set to prevent any dialogs from being shown. > > I have already mentioned that I will probably replace this with either a > Kill or DeleteFile call. now I think I'd put it pretty high up in my candidate list of problematical external routines particularly since what isolation you've been able to do so far seems to point in this general area. It's (the SHFile... routine, that is) just got _so_ much baggage associated w/ its operation I have no problem at all believing it might have some internal bugs even if your data/usage _is_ correct (and again, I repeat, the amount of stuff required to set up for the call is suspicious of perhaps there being a problem). >> Anyway, unless there was some very good reason for use SHFileOperations Dang! Shoulda' seen this earlier...but I'll leave the comments >> I'd ditch it on the general principle of parsimony--what's the point when >> there's a much simpler way? > > I'm sure there was a reason I did this back in 2006 when I wrote the code > for the DLL. Honestly, I can't remember it right now. > >> So, I'll say that change is one of the first I'd now recommend along w/ >> still looking _VERY_ closely at any and every API call; OS- or >> vendor-supplied. > > Agreed. .... anyway... :) Good luck...one last thought and I'll leave you to it until there's some other development--perhaps there's some way to more fully characterize the results of the scan/barcode operation/whatever other external events are occurring to log as well as simply a completion call stack event logging but pertinent characteristics of the operation that are used later--like filenames, lengths of file(s), proper characteristics of any header/trailer/id fields, etc., etc., that my leave some bread crumbs along the trail if there is a partial success but not complete. Oh, you are testing any and every return value of every API call aren't you???? No chance of one of these routines that "shouldn't" ever fail but returns an error code that isn't look at kinda' thing. The classic example is the malloc() that isn't tested. Or, of course, there's always the possibility that there's a misallocated buffer to one of these APIs--any chance at all the scanner/barcode/whatever can overrun a buffer on a fluke condition? All kinds of nasties can happen then.... -- -- dpb wrote:
.... > Good luck...one last thought and I'll leave you to it until there's some Actually, I had one other thing that came to me...nothing profound and > other development--... probably have at least noticed it but think it's worth commenting on specifically--that is, that it appears that despite the apparent randomness of the occurrence, the symptom is reproducible. I think this is more of a hint than mayhaps been explicitly recognized--whatever it is, it is the same thing happening and it has a predictable effect. Consequently, that nearly convinces me there is a failure in one of the steps that ends up w/ a specific set of conditions--obviously I don't know if it's at the scanner, the barcode or somewhere else, but I'm thinking if you look at the details of what each step is to do under a sufficiently powerful microscope you will discover a specific problem. It again makes me question the firmware/hardware as the underlying generator of the data being processed. What if there's an internal power glitch onboard one of those devices that forces an internal reset as a wag? I've worked a lot of embedded systems over the years and all sorts of bizarro things can happen w/ some external devices one never expects w/ the normal PC (even w/ Windows :) )... Anyway, just a thought of how it strikes me... -- Have you tried the RSTools option?
-- Show quoteHide quoteRandem Systems Your Installation Specialist The Top Inno Setup Script Generator http://www.randem.com/innoscript.html Find Out What Your VB Program is Really Doing http://www.randem.com/rstools.html "Al Reid" <arei***@reidDASHhome.com> wrote in message news:urO0OMw$JHA.1376@TK2MSFTNGP02.phx.gbl... > "Randem" <newsgro***@randem.com> wrote in message > news:eK6BW4v$JHA.4432@TK2MSFTNGP05.phx.gbl... >> Then the only way to tackle the issue is for us to have the project and >> data that causes the problem. I am sure I can find it. Is this request >> possible? >> >> -- >> Randem Systems >> Your Installation Specialist >> The Top Inno Setup Script Generator >> http://www.randem.com/innoscript.html >> Disk Read Error Press Ctl+Alt+Del to Restart >> http://www.randem.com/discus/messages/9402/9406.html?1236319938 >> > > I appreciate your offer. It is a large project that includes a main > application, an ActiveX Exe that wraps a 3rd party scanning OCX (wrapping > done to make the scan component asynchronous), a custom DLL, 3rd party > barcode reader and Oracle/File server. > > To complicate matters, there is no set of data that "causes" the problem. > If I had a set of data that would repeatedly cause the problem it would > have been solved by now. When it fails, I can manually e-run the file and > data stream through the same code and it will assemble. Also, if I rescan > the same batch of paper, it will not fail the second time. That has been > the real issue with solving this issue. It seems to be purely random and > not repeatable. > > Also, I have now experiences two failures with all debug logging turned > on. Both times the failure occurred during a call to the DLL to delete a > page and corresponding database entries. There is a debug log statement > before and after the call to the DLL. The call to the DLL is logged, but > the return is not. The error logger is logging the call and return from > the Assembly routine. The call is logged, but the return is not. > > If the next failure occurs at the came DLL call I will change the code > that deletes the file from SHFileOperations to either DeleteFile API or VB > Kill function and see if this changes anything. > > Thanks, > > -- > Al Reid > > > For several years I had similar but multiple random problems, which
could only be caught by stepping through the code until a call went to the wrong place. The counter-intuitive solution, that saved my sanity, was to move entire suspect procedures into a fresh module. Complete rebuilds and re-installs followed. 
Other interesting topics
PowerBASIC
String Memory Recovery Web Pages in a VB Window? Inno Setup and Dependencies The JET VBA File...Help Please! can i do this with real database, not just dataset Proxy + ADO + VB6... Checkbox - how to clear without triggering click event Macro to Print Text to file in UTF-8 Re: Sending email |
|||||||||||||||||||||||
