6.40b4.1948 - Crash via corrupted call stack

[driverdude]

6.40b4.1948 - Crash via corrupted call stack (repeatedly)

very clean system, brand new install, first day using

I would be glad to run a debug version (built with each stack element protected, stack sniff, stack range bounded), or use a postmortem crash tool to help you resolve this crash issue if you have a RAM resident black box that is dumpable to text for you.

Windows could not return the location of your crashes PROBABLY because the call chain from the stack itself was corrupted so windows merely made a hash ID as a type of location identifier (near useless in my opinion). Here are two crashes :

Problem signature:
Problem Event Name: APPCRASH
Application Name: NewsbinPro64.exe
Application Version: 6.4.1.0
Application Timestamp: 4fe3c056
Fault Module Name: StackHash_c4a3
Fault Module Version: 6.1.7601.17514
Fault Module Timestamp: 4ce7c8f9
Exception Code: c0000374
Exception Offset: 00000000000c40f2
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: c4a3
Additional Information 2: c4a3fb55fd74ab6fc5748c960b4a6f59
Additional Information 3: c123
Additional Information 4: c123ccc1eaa9a47ff8c7ceb620b501b4


Problem signature:
Problem Event Name: APPCRASH
Application Name: NewsbinPro64.exe
Application Version: 6.4.1.0
Application Timestamp: 4fe3c056
Fault Module Name: StackHash_c4a3
Fault Module Version: 6.1.7601.17514
Fault Module Timestamp: 4ce7c8f9
Exception Code: c0000374
Exception Offset: 00000000000c40f2
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: c4a3
Additional Information 2: c4a3fb55fd74ab6fc5748c960b4a6f59
Additional Information 3: c123
Additional Information 4: c123ccc1eaa9a47ff8c7ceb620b501b4


To prevent MORE crashes, I will toss the massive downloads list, as I predict you shall suggest and advise, (I backed it up with program closed PRIOR to session test, prior to any files downloading), but i will keep the 8500 files already present and then hand wipe from the saved DB after loading the first 8500 from the list, or so. So the crash in the future cannot be blamed on a corrupt DB file, but i DO wish they updated to disk more often DESPITE fear of corruption, due to crashes being a part of life it seems and having to "redo" things that were done, such as moving files to bottom of download list (seems to not write out if app crashes) and other issues.

ENVIRONMENT :
SEMI VIRGIN SQUEAKY CLEAN new Windows 7 pro 64 install with NOTHING much happening
Quad cpu , 8 GB ram
Install was 64 bit version

DEMO MODE, not registered, hopefully demo DRM was not running and causing crash. I will register soon, Its my second day in my life exposed to this product and I spent a week testing many other products looking for a new usenet reader, so i had not yet registered, and reader was on day 2. (1.5 technically)

data folder : REDIRECTED to another volume
giganews with astraweb as backup fill
I have the saved downloads list prior to running and subsequent crashes.

Machine set to never power sleep, except screen. Hard drive ticklers not running but both hard drives mounted were active and never spun down, one held C: and data volume, the other active drive held usenet mp3 destination.

===============

I 10% SUSPECT IT MIGHT HAVE TO DUE WITH PACKET LOSS OR PACKET DELAY : After the first 50 gigabytes, comcast throttled me to 334 kilobits per second, around the time of the crash, the second crash was a after relaunch under similar I/O conditions. Maybe fills from astraweb were highly interwoven? I saw nothing exotic in opened already error log window.

SECOND POSSIBLE SUSPICION : my unique settings for PAR actions from this app, and an anomaly seem after a pause and restart
Meaning : second launch was trying to download a ton of previously downloaded par2 files that were already on disc and I had fingerprint ID technology to avoid dupes always disabled. The files on disk never changed, but the app seemed to be walking through the list. I then after a crash int eh future moved them ALL to bottom of list, though that state was not preserved because of a second crash, but maybe extra pars in list are part of it? All I want in life is to select a ton of files and have them all get saved in selection order, to a destination drive. Using them for fill server logic is fine though, so long as all par2 files get saved ONCE to disc.

except a first time stress test of product downloading 173 GB of mp3 files in one long list to ONE single directory. Crash was AFTER a test pause, long wait, app close, app relaunch and then many hours later using two usenet providers at full on speed, a first crash.

MY ONLY MAJOR SETTINGS CHANGES TO NEWSBIN (other than adding one group, using a backup fill server, and moving app data) :
Download age : 60
Display Age : 5000
Storage Age : 5000
Use Image DB : unchecked ( i think it came checked)
Automatic update mode : UNCHECKED
Filename Option : MP3 folder mode UNCHECKED (i think default might have been checked)
Filename Option : SAve File summary : CHECKED ( my FAVORITE MAIN FEATURE OF THIS PRODUCT : the NTFS ADS stream Comment holding the usenet subject) widh it had uploader too. Works great under windows 7, when using custom tools to probe files)

Autopar : ONLY have on item in dialog check and its a subcheck that is probably irrelevant : "Remove Repaired but not unrared sets in download list"

File Descriptions : CHECKED (love love love this feature as second favorite part of product) i dont recall if default is unchecked

COLORS FONTS : changed background color of "partial downloads" changed font to smaller point size for all

Advanced : Use Duplicate Detector : UNCHECKED : (it still will silently fetch anyways, and fingerprint was only file start portion anyways) par2 set ID is the only GOOD way to avoid file dup downloads. possibly sfv too

Advanced : Show File Age : UNCHECKED

==============
THIRD CRASH POSSIBILITY (long shot) : too many files ?

destination folder was at about 8500 items (all files, no directories, i use my own directory sorter tools farther alone, way later) in ancient times, that was an issue for OSes but NTFS in widnows 7 should not barf until limit. Old limit was 65534 files in a directory, new limit in actual observed testing accoring to a microsoft engineer is "several million files" in one directory

volume was freshly formatted and had over 700 gigabytes free before stress testing of newsbin

==============
I can do anything you want me to do on this end to help you if needed, or run a debug build, forensic tool, or post my large uncorrupted downloads.db3 for you, though I/O packet via two servers would not be the same result, but who knows maybe its the items in the list regardless of low level traffic.
=======

Thanks again for creating such an amazingly cool product.

[Quade]

At this point I consider it an issue with you running a "bleeding edge" version. I have a feeling B4 didn't get completely rebuilt when it was built and has some old libraries in it. I think it unlikely that this is caused by something external like packets. Newsbin never even see's packets. All it see's is a stream of data from the servers.

It's probably just a run of the mill bug. I might try to get you a version of B5 to try since you can crash it pretty readily.

[driverdude]

WORKING FINE AGAIN IN THIS FIFTH USAGE LAUNCH SESSION

Thanks. No need. I no longer can make it crash , at least in the current session of 3 thousand more files in the last 3 hours, but the first crash was over 6 hours in when it happened.

In prior bootup of machine I had 4 crashes, each SEEMED to be when Par2 files were clinging to list top on a relaunch of the app as soon as IO resumed, but at the same time, I was also being throttled to 5% throughput by comcast on this business line with a year and a half left on the contract.

Now i try to RAPIDLY pause the DL stream as soon as DL list is loaded, though list does start a tiny few milliseconds before my click.

After opening up files list of frozen IO, I delete the top scruff I do not want and move the unwanted finished par2 to list bottom, then save and close down and THEN relaunch with clean new files at list top.

no crash. I then also set throughput limiter to avoid comcast getting irritated at my abuse (long story, but I actually use my line at reasonable usage rates averaged over months). Your rate limiter is now applied. "RESOURCE MONITOR" tool in Windows 7 confirms it. NICE FEATURE.

After working around comcast ban hammer using original MAC hardware provisioning code from original order and letting modem (my own personal) stay detached for 3 hours instead of typical 17 minutes (was still banned on NEW IP after 17 mins!), I got my speed back, when i got a new IP from DHCP. After waiting until late nite to start newsbin stress test, I now see no problems.

b4.1948 is apparently acting good again.... i will let it go nonstop.

There is always a chance the tools launched at start play a role, but i set Catalyst AMD control center to not open ports and update during the session the crash happened. Also in that crash I had not run ANY apps except notepad, firefox and explorer, and do not use any third party drivers other than video and killed windows network sharing for media center prior to session. There were only minor things in OS doing net traffic.

If i can ever make it fail again today I will let you know, i have a day of IO queued up, but my goal is to get it to 10 hours in one directory, then start a new directory in a new launch. 2 runs per day was my usage test goal. I am not even trying to use this win 7 machine except for this firefox and notepad on occasion. I have 3 other machines running but keeping them mostly light use of the net today to keep IO at constant speed.

I have file window open wide, on a second monitor, and showing cool progress bars, as before, to keep newsbin working harder, and have critical error window open and semifront ALREADY in case that has anything to do with it (raising and revealing with other coincidental issue) also so i can read it if the app crashes a fifth time ever this week. All the crashes were in a one hour time period when my io was throttled by comcast, but that may be a red herring, other than higher reliance on fill server perhaps.
I am DELIBERATELY selecting 175 gigs of test files that for whatever reason, are more incomplete than normal (6%) from 3 years ago on giganews and need fill servers to complete without using par2.

ALL SEEMS FINE

[driverdude]

STILL RUNNING FINE and crash not reproduce-able in a long 16000 file marathon stress test session.
After 18 hours , I closed down the app to give it a rest and restart.

Thanks for designing such an amazing product

[Quade]

During a code review, I found a crash inducing bug. In the beta for sure and maybe in 6.34. It would be file specific so, that might explain why it works some times and not others. Dex is out so, I might have to find a creative way to get it out to people.

[driverdude]

In 12 hour long second stress test, after it worked fine for yet another nearly 19 non-consecutive hours, and today 12 hours, it crashed in same stack hash location. I saved every db file before the stress test, but a few UI actions were performed an hour before the crash and it uses two server services so having copies of the the test file list might not be fruitful. Sadly , it had been going non stop for nearly 12 hours this crash, so simplistic reproduction might prove difficult, but possible. I predict I MIGHT be able to repeat i quicker : save the current possibly corrupt files, and let it go again, and if it crashes, then at least it might happen sooner rather than 12 hours away and therefore might be semi helpful, but you never know if this is or is not related to the issue you just fixed today or not.

thing done prior to crash : highlight range of "complete" par2 set portions that oddly collect at top, in a nonattached file list window, though I desire all files of a par2 set, and plan on doing my own par2, but also after FILL SERVER seems jammed or fallen very very far behind **OR** more likely .. fill server needing a kick in the pants to retry and resume a pile of files needing a little missing piece here and there that collected near the top but after the par2s already ONCE xfered to disk. the mere act of moving the list around woke up fill server and hundreds of small files RAPIDLY got completed, then I walked away... then app crash. Sorry I am not much help, but if you ever get a new normal official beta I will notice announcement and switch to it to use.

The LAST time is first crashed was when I moved a pile of pars at the top of a list toward the bottom in non-pause mode. I did it 3 times before in pause mode seemingly with no near-future ill effects. Maybe I will pause the xfers before tampering with a absolutely massive to-do test file list.

There are over 60,000 medium size files in the testing list, with an unknown amount of messages per final file asset, but my gut feeling is this app can probably handle millions of to-do and nearly as many half-finished, and I mention sizes only in case lag or event delay can ever play a role.

Ohhh... and the app was regged prior to run and relaunched and run in reg mode.

Sorry I am not much help. If you create a cyclical-ring-buffer post mortem message table, interrupt thread safe, with a tag scannable from a priv process after a crash, then such a forensic black box might be of use in reporting these more pesky types of crashes with a messed up or unknown stack history.... even if its merely "in" "out" messages of certain calls. Anyway, its at least 99.99999% bug free in terms of solid work output per day.

Problem signature:
Problem Event Name: APPCRASH
Application Name: NewsbinPro64.exe
Application Version: 6.4.1.0
Application Timestamp: 4fe3c056
Fault Module Name: StackHash_c4a3
Fault Module Version: 6.1.7601.17514
Fault Module Timestamp: 4ce7c8f9
Exception Code: c0000374
Exception Offset: 00000000000c40f2
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: c4a3
Additional Information 2: c4a3fb55fd74ab6fc5748c960b4a6f59
Additional Information 3: c123
Additional Information 4: c123ccc1eaa9a47ff8c7ceb620b501b4


good job finding a plausible culprit so quickly

[driverdude]

CRASH!
That crash happened the last two days again. once after 15,599 files, and once after 1784 files Including descrip.ion.

descript.ion only held 1780 files, but I am extracting the UPLOADER name from the author comment hidden in the invisible NTFS SummaryInfo ADS your tool hides there, ties to every file, and the SUBJECT from the comment you hide there in ADS and skipping trusting the descript.ion file for now for that data. Mainly because descript.ion was a few files behind the hard drive save point during crash.

I guess I will revert or look for a stabler build beta version as soon as I can, and maybe it is a specific item situation you referred to.
I saved all the data files before the stress test attempt so I could replay it from there since its only a lose of 6.9 gigabytes (the 1784).

I will do that now to see if that is the case, it might do it exactly at 1784 files again if that is the case. Ii'll let you know.

[Quade]

viewtopic.php?f=44&t=30541&p=185967&sid=25acc900ab3c6cc3e85884910a6876e4#p185967

Something to try.