L4 Indexing stops working or crashes
I have been trying to get L4 to complete the initial indexing for almost a month now. The indexer crashes or stops working before even getting halfway through the process. This install was originally an upgrade from L3 which tech support could not get running after I upgraded from Windows XP SP2 (also about a month ago). My system config is
ASUS M2N-E Motherboard, AMD Athlon 64 X2 processor, 8GB RAM, Windows 7 professional with all updates installed, .NET 4.0 with all updates installed (recommended by Logos Tech Support), Norton Internet Security 2011, Office Home 2010 etc.
The indexer hangs on certain resources which are removed and indexing restarted, replaced and indexing restarted, etc. In addition, I have been instructed by logos technical support to remove directories and restart the application, update resources, and rebuild the index...all without success. The last thing I was asked to do was to reinstall L4.
Ever since I reinstalled I have had some BSODs with Memory Management and page fault in non-paged area, etc. When I look at the crashdumps in appcrashview, this is what I see (these are the last 5):
Logos4Indexer.exe Stopped working 10/14/2010 8:35:39 AM jjohnson 0xc0000417 0x0006c955 MSVCR90.dll 9.0.30729.4926 C:\Users\jjohnson\AppData\Local\Logos4\System\Logos4Indexer.exe 20,788 C:\Users\jjohnson\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_Logos4Indexer.ex_8ac7cbb4e0f046b6914ba9b6bff74c78f9e4a9_10eded6a\Report.wer
Logos4Indexer.exe APPCRASH 10/14/2010 7:58:02 AM jjohnson 0xc0000005 0x00062374 mscorwks.dll 2.0.50727.4952 C:\Users\jjohnson\AppData\Local\Logos4\System\Logos4Indexer.exe 20,218 C:\Users\jjohnson\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_Logos4Indexer.ex_d334b1e38433ac2b369130667c90c5366a762ad_07aa7b85\Report.wer
Logos4Indexer.exe APPCRASH 10/14/2010 6:09:24 AM jjohnson 0xc0000005 0x0002e1fe ntdll.dll 6.1.7600.16559 C:\Users\jjohnson\AppData\Local\Logos4\System\Logos4Indexer.exe 20,376 C:\Users\jjohnson\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_Logos4Indexer.ex_8a181d29256f3176b92d17aba408ca2a81392fe_08198dbe\Report.wer
Logos4Indexer.exe Stopped working 10/13/2010 10:04:16 PM jjohnson 0xc0000417 0x0006c955 MSVCR90.dll 9.0.30729.4926 C:\Users\jjohnson\AppData\Local\Logos4\System\Logos4Indexer.exe 20,966 C:\Users\jjohnson\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_Logos4Indexer.ex_8ac7cbb4e0f046b6914ba9b6bff74c78f9e4a9_0d357994\Report.wer
Logos4Indexer.exe Stopped working 10/13/2010 9:33:15 PM jjohnson 0xc0000417 0x0006c955 MSVCR90.dll 9.0.30729.4926 C:\Users\jjohnson\AppData\Local\Logos4\System\Logos4Indexer.exe 20,966 C:\Users\jjohnson\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_Logos4Indexer.ex_8ac7cbb4e0f046b6914ba9b6bff74c78f9e4a9_0ec11dcd\Report.wer
As you can see, the problems are with Win 7 components. The last words I got were that if it happened again I needed to take it up with Microsoft. With the variety of conflicts with L4 and native windows DLLs it is not an OS problem since the rest of my applications play nice with them. I have attached the last indexer log...I'm waiting for another crash.Anyone have any ideas?
JP
Comments
-
James Johnson said:
Ever since I reinstalled I have had some BSODs with Memory Management and page fault in non-paged area, etc. When I look at the crashdumps in appcrashview, this is what I see (these are the last 5):
It's impossible for a "user mode" application (like Logos 4) to have a bug that directly causes a BSOD (since it's the OS's job to prevent that), so this points to an underlying hardware or driver problem. The Logos 4 indexer is a very RAM and CPU intensive application, and the extra load it puts on the computer can possibly cause problems that don't show up under light usage. (See also http://community.logos.com/forums/t/17747.aspx.)
I recommend running a stress test on your computer to rule out (or confirm) the possibility of hardware issues. Please download Prime95 from http://mersenneforum.org/gimps/p95v2511.zip (assuming you are running 32-bit Windows; see http://www.mersenne.org/freesoft/ for other versions of the software). This program is commonly used for stress testing hardware (http://en.wikipedia.org/wiki/Prime95#Use_for_stress_testing).
After you unzip it and run prime95.exe, it should ask you if you want to join PrimeNet or just run a Stress Test. Choose the Stress Test option, then the "Blend" option (the default) and let it run. It will be best to start this at the end of the day and let it run overnight. If it's still running with no errors in the morning, then your system has a clean bill of health. If, however, your computer has blue-screened, rebooted, turned off, or Prime95 is reporting an error, then it's likely that there's an underlying hardware problem that is causing the crashes in Logos 4.
0 -
Thank you Bradley for the info,
I have run stress tests on the machine. And as my post indicates, I'm running 64 bit Windows 7. By process of elimination, the BSODs only occur when trying to run Logos 4, all other times (considerable) there are not any problems. In addition, I ran memtest to see if there was something that caused the following indexer crash a few days ago:
Error ID: 5438
Error detail: AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at SinaiLib.TitleLoader.{dtor}(TitleLoader* )
at SinaiLib.TitleLoader.__delDtor(TitleLoader* , UInt32 )
at Libronix.DigitalLibrary.Logos.LogosResource.IndexContent(IIndexer indexer, ResourceManager resourceManager, ReverseInterlinearManager reverseInterlinearManager, ResourceClassifier resourceClassifier, IWorkState state)
at Libronix.DigitalLibrary.LibraryIndex.IndexNextResource(ILibraryIndexWorkState state, Indexer indexer)
at Libronix.DigitalLibrary.LibraryIndex.DoBuildIndex(ILibraryIndexWorkState state, Int32 nResourceCount, String strIndexName, Int32 nIndexableResourceCount, Int32 nMaxAdditionalThreads, Boolean bShouldMerge)
at Libronix.DigitalLibrary.LibraryIndex.BuildIndex(LibraryIndexWorkState state, String strIndexName, Int32 nIndexableResourceCount, Boolean bShouldMerge)
at Libronix.DigitalLibrary.LibraryIndex.IndexResources(IPausableWorkState threadOwnerWorkState, LibraryIndexWorkState state)
at Libronix.Utility.Threading.WorkStateThreadOwner`1.ThreadProc(Object objData)
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart(Object obj)
both the stress test and memtest showed no problems with the hardware. So its interesting based on what your saying that a user mode application wouldn't do this, or I'm misreading the stacktrace....having programmed in C++ and in C# in past years, I'm not sure that this can't happen. In theory the .NET shouldn't let it happen. I say not sure, since I prefer to work in Java in my day job and have been a software architect for the last 8 years.
LOL Let me know if you have any other ideas as I'm really puzzled by this one.0 -
Oh, forgot to say what the stress test software was, BurnInTest by PassMark software...
0 -
Umm James...
sorry if this seems too simple but I've been a logos customer for years and have had various problems...especially with the Logos 4 roll-out. I have a pretty large library built up over the years...and all I did was call tech support and worked with them = problem solved. And not just one but a few.
Maybe that's the way to go...maybe you've done it but it just seems to me in my experience with logos - they don't want someone out there that can't index their library and use the program to its fullest capabilities.
Hope this helps.
0 -
James Johnson said:
In addition, I ran memtest to see if there was something that caused the following indexer crash a few days ago:
Error ID: 5438
Error detail: AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at SinaiLib.TitleLoader.{dtor}(TitleLoader* )
at SinaiLib.TitleLoader.__delDtor(TitleLoader* , UInt32 )
This type of crash could definitely be caused by a corrupt resource file on disk; the full log file would probably indicate which file the indexer was reading when it crashed. Since our resources are (mainly) read by native code, it's quite possible for a bad resource to lead to memory corruption.
Logos 4.1 contains some code that makes it difficult to always correctly analyse what's going on in these types of crashes. In Logos 4.2 Beta 2, I added some new code to try to better pinpoint the problem with bad resources.
In the original log file you posted, exceptions were thrown when indexing the following two files. As a start, I'd suggest moving/deleting those files, and seeing if the indexer gets any further without them.
C:\Users\jjohnson\AppData\Local\Logos4\Data\cng0cgra.s4w\ResourceManager\Resources\AV1873.logos4
C:\Users\jjohnson\AppData\Local\Logos4\Data\cng0cgra.s4w\ResourceManager\Resources\LIONINTOT.logos4
0 -
J.
Thanks for the insight, but I have been on the in contact with/on the phone with technical support since Tuesday. This all started when I tried to get Logos 3 working on my machine. They could not get that working, so I agreed to upgrade to Logos 4. No luck. I have tried everything they asked, including installing .net 4.0 which beforehand my system was not BSODing. As of today they say that they can't do anything to help and to talk to Microsoft. So much for help. So posting here was another of their recommendations, and so far no real solution. I'm not a fan of .NET because in the enterprise business world I have seen disaster after disaster. I'm currently using WinDBG to read the crashes that even occur in safe mode when using the Logos 4 product.
If I sound frustrated its because I am and didn't think that a product and company I have been loyal to since 2003 would turn their back on a customer. But I'm thankful that I purchased BibleWorks which doesn't seem to have these problems.
Anyway, thanks again for your comments.
0 -
Bradley, been there done that...more than once, doesn't help. I have even (at tech supports request) deleted the entire resource directory and reloaded it. No help. At this point I'm thinking about just wiping the box clean and starting over again. This especially since tech support left me high and dry.
Any other suggestions?
Jim
0 -
Here's the latest BSOD episode...files attached, they include the logos4 log, logos4crash txt, the logos4indexer log, the logos4indexercrash txt, and the windbg crash analysis (didn't have all the symbols loaded since I don't have VS on this machine). To date there have been 5 different Windows DLLs (like NT.DLL, etc.) that are involved in the indexer crash/BSOD. The system runs fine with any other application, 64 bit, 32 bit, and even a couple of 16 bit programs I have.
I'm willing to keep troubleshooting as long as someone is willing to not quit like the tech support did. But if I'm wasting my time here, let me know, I have my disks out and will start to wipe the drive and start over.
0 -
Hi James,
I'm not sure what to tell you here. My reading of the crash analysis (thanks for including that!) tells me that Logos4Indexer is just the hapless victim. The actual problem is a "VISTA_DRIVER_FAULT" that is "Probably caused by : ntkrnlmp.exe ( nt!SwapContext+6d )". ("An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses.") I'm not an expert at reading kernel-mode dumps or x64 assembly, though, because I never have to do that. [:)]
A BSOD is caused by an error in kernel-mode code (either OS or driver). Logos 4 doesn't include any drivers of its own, so it's not directly responsible for this crash. (The kernel should be sanitising any values passed in from user-mode code so I'm not sure that we could write any code that causes a BSOD even if we deliberately tried to do so.) You'll also note that the crashing code is 64-bit; all Logos 4 binaries are 32-bit.
If you were able to capture a user-mode dump of Logos4Indexer crashing (e.g., by using ADPlus, http://wiki.logos.com/Creating_a_Crash_Dump_with_ADPlus), I'd be happy to take a look at that for clues on why the indexer crashes (when it doesn't BSOD).
But if you're ready to wipe the OS and start over, I'm also willing to wait and see if there's still a problem after you've done that.
(And when you do reinstall, there's absolutely no need to install .NET 4; I'll have a word with Tech Support about that.)
0 -
Bradley, thanks, I'll try that before I spend the time reinstalling the OS and apps. One thing I thought of last night, you are right, the os component is the victim. However, it can only take whatever parameter is passed by the application. In several of the stack traces and logs I thought I saw "invalid parameter" in there. I'm a bit rusty at this but parameters that use pointers can be unsafe (I read that somewhere). For instance, C# supports pointers in a limited extent. C# statements can be executed either as in a safe or in an unsafe context. The statements marked as unsafe by using the keyword unsafe runs out side the control of Garbage Collector. In C# any code involving pointers requires an unsafe context. Its here that I was thinking it may be possible for a bad parameter to cause a problem. But I'm just not sure, I have read a bit in VS developer forums about these types of errors and its possible for an application to do what I'm seeing; but these discussions are at compile time and usually involve debugging the application.
I'll try the ADPlus stuff and see what it captures.
Thank you for helping me...the irony of this whole ordeal is I can still used the product without indexing and actually love the interface and features. But without indexing I'm left to human memory where things are - not a good way to read and study the Hebrew and Greek scriptures... LOL
Jim
0 -
Ran the tool, walked away and then came back, it just seemed to sit there for a while and did nothing, so here's the logs...let me know if there are commands you want run in CDB.
0 -
Bradley, O.K figured you aren't working on the weekend and ran CBD on the indexer only and executed the commands to continue to the next call and then did a break. I'm going back and doing the logos application but wanted you to see where the indexer hung on a resource. I'll send that along sometime tonight. attached the indexer only run just for information. Maybe you can see something in the stack traces.
Also, it appears that I don't have all the symbols loaded, not sure what to do about that, since I'm not sure I can get access to them. Hope your having a good weekend.
Jim
0 -
Bradley,
Had a more full run (this one captured a lot of stuff) and decided to run the go command and just let it run...still wasn't sure what you wanted me to do in the debugger since I don't have access to the source code. But at least I'm seeing more information. Twice now I have seen crashes with an unsafe native method call (remember what I said earlier) using SQLite (the db that L4 uses?). There is a full dump (.dmp) that was generated, but it was to large to upload. The last one was this morning and the machine didn't bsod - I was able to continue my study after the indexer died. File I'll send that next. Thats it for now, I'm not allowing any more indexing and will wait to see what you recommend.
Jim
0 -
-
I didn't actually want you to debug it, but just to see if it was possible to collect a dump file that I could debug (with full symbols) here. [:)]
The log files definitely seem to indicate process memory corruption but I'm still unsure where it's coming from. Perhaps corruption in the resource files that are being indexed is causing a buffer overrun and heap corruption in our native code.
I've attached a simple console app that will compute a checksum for each of your *.logos4 resource files (in %LOCALAPPDATA%\Logos4\Data\cng0cgra.s4w\ResourceManager\Resources) and report if it detects any anomalies. Please redirect its output to a file and attach it here. (Also, please let me know how many *.lbxlls files you have in that folder; this tool currently doesn't check them because they're in a different format.)
0 -
-
file you requested, and the debugger was kinda fun. Anyway, I had read somewhere else where there were bad checksums. All of the resources were downloaded over the internet as well as the core installers too.
0 -
I was able to verify that the checksum was correct for all but seven files. (And those files aren't necessarily bad, it's just that I don't have the exact same version of that resource on my drive as you do, so I can't compare them directly.)
Recent versions of Logos 4 have safeguards to protect against download corruption, and 900+ resources without corruption (including some large resources) makes it seem unlikely that a corrupt file is the problem.
Logos 4.2 is currently in beta testing (see http://community.logos.com/forums/t/8883.aspx). It has some changes to the indexer to help us troubleshoot problems like this more easily. If you're comfortable running a beta version, the logs it produces may help.
However, the repeated BSODs on your system do point to a cause outside Logos 4. A memory corruption issue (from some external cause) has the capability to crash Logos4Indexer.exe (if it modifies user mode memory) or the entire system (if it modifies kernel memory). We do have some "unsafe" and native code in the indexer, but it's still user-mode code that's isolated from the OS kernel. Passing invalid parameters to kernel functions or trying to write to kernel memory will crash the application (not cause a BSOD).
0 -
Bradley,
Thanks for the info, I'll look into the beta release to see if it helps.
Jim
0 -
Bradley,
I figured the problem out, it wasn't Logos 4 or the Windows 7 operating system. I was talking to another programmer and he mentioned to me something I hadn't thought of. There was nothing to lose so I tried it. Come to find out It was an issue with AMD processors and the RAM. Evidently there is a heating issue when running Logos 4 or other CPU and RAM intensive apps. I tested it with a cooling fan directly into the case and the product indexed without failure. Whoo Hooo! LOL
Anyway, you mentioned some resources that didn't seem to have the versions, could you let me know which ones?
Jim
0 -
James Johnson said:
I tested it with a cooling fan directly into the case and the product indexed without failure.
Hey, that's my trick with the laptop (but it just "clicks off" so you know it is overheating)!
Dave
===Windows 11 & Android 13
0 -
James Johnson said:
I figured the problem out, it wasn't Logos 4 or the Windows 7 operating system. I was talking to another programmer and he mentioned to me something I hadn't thought of. There was nothing to lose so I tried it. Come to find out It was an issue with AMD processors and the RAM. Evidently there is a heating issue when running Logos 4 or other CPU and RAM intensive apps. I tested it with a cooling fan directly into the case and the product indexed without failure. Whoo Hooo! LOL
I'm glad to hear that you figured it out. (That sounds like a vote of no confidence in BurnInTest if it "passed" the system when there was clearly a stability issue.)
James Johnson said:Anyway, you mentioned some resources that didn't seem to have the versions, could you let me know which ones?
I saved the list to a temp folder, so it might have been deleted, but from memory it included FRESHSERMS, LOUWNIDA and SGNTGLOSSARY. These files are very likely to be completely OK; the only "problem" was that my test system didn't have the exact same files as yours.
0 -
Its ok I checked and everything is up to date. For some reason when I run memtest86 or burningtest, the problem doesn't manifest. Weird. I run speedfan now to make sure the fans on the CPU and GPU are monitored and increased in speed if there is a heating problem. I was thinking about water cooling for the CPU but it would not really help the RAM heating issue. Thanks again for hanging in there.
0 -
I had the same problem with BSOD when trying to install L4 to my new Windows 7 64-bit. I read to the end of this thread and saw the suggestion that an AMD processor was overheating. I do have an AMD processor, so I opened my case, pointed a house fan to the system, indexed L4, and it did work.
0 -
Bob Weber said:
pointed a house fan to the system
I thought you pointed a hose at it for a minute!
I'm glad the cooling fan worked!
Dave
===Windows 11 & Android 13
0
