logo
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

2 Pages<12
Telenet Crashes
vk4iu
#21 Posted : Tuesday, March 26, 2013 7:26:46 PM(UTC)
VK4IU

Rank: Advanced Member

Groups: Moderator, Registered, Administrators
Posts: 404
Man
Location: Hodgleigh QLD

Thanks: 6 times
Was thanked: 77 time(s) in 68 post(s)
Hi John,

That's not good news, John. It does not look like anything has changed for you - despite any actions you take. In the old days it was called "Windows DLL Hell". These problems are extremely difficult to solve. With expensive and extensive Windows debugging tools, and lots of experience, it is easier, but still difficult.

Sadly, it is my observation that these problems occur often with Amateur Radio software of various types. It is not for nothing that there is a "Microsoft Certification Process". Unforunately, it is a process that is well beyond affordability for Amateur Radio Software developers. Secondly, there are but thousands using Amateur Radio software, and given the small numbers, it is highly probable that there are only a FEW of us using any one combination of such software and systems. And lastly the "documentation" from Microsoft on the techniques to avoid these problems is absolutely vast and rarely completely read by anybody outside the big players. Most software developers simply "start coding" and deal with the problems "as they happen".

Programs don't have to be running to have an effect. For example, any software may add/update/change drivers or DLLs that lead to errors in other software. Item A installs driver ver 2.3.4, but item B needs the older 2.3.3b to function. Been there, done that, with MicroHam software and Eltima drivers, Java runtime systems and many others. Think of programs as having a "front office", that you look at and interact with, and a "factory" out the back. Anything can be happening in the "factory" out the back, even if the "front office" is closed for the day.

You have little choice but to be working on things external to Logic. If Dennis has given Logic the tick of approval, Logic must be the trigger, not the problem. And the only constructive technique, where you and I sit in the grand scheme of things, is a slow process of selective elimination, until the problem stops or starts.

Yes, I understand what that means. I have been in your situation many more times than I care to relate - the memories are too painful. In my past 45+ servers and 4000+ PCs made for too many suppliers and too many combinations.

Clearly, you could simply abandon Logic, and ignore the problem. But, if you don't keep after this problem in your system to find a solution, you many never trust your system again. It will come back to bite you when you least expect it.

There are no easy steps to a solution in a problem of this type. Nothing is certain, but all of the Windows installed "multitude of programs in todays Windows computers" were mosty certified by Microsoft. It is the ones you installed that we most likely need to be thinking about.

I realise I am "shooting in the dark". You are on the front line - and I respect any descion you make. I just hope I am helping in some small way.

TCP/IP seems to be involved in both your Logic errors ...

Quote:
The REPORT ERROR only occurs if the Spot Log form is open at the same time as the report is being generated.

The EXPORT CRASH occurs if Telnet is running or if it runs later in the same session.


Start with the most obvious "big" things - run "error checking" on the hard disk for example. Secondly, uninstall the smallest of things - the software that is likely to have the smallest number of users, is simply cosmetic, clocks, screen savers, internet bandwidth monitors, stuff nice to have but not essential, and the least likely to be certified. Microsoft's tools, Outlook, Word, Excel, and Adobe's tools, Reader, Flash etc, and other items from "well known big brands", have all most likely been certified and are the least likely to be the problem.

Selectively uninstall any "amateur radio" software. Test using your "trigger" after each step. Suspect anything that goes against the accepted "standards" - like using an RS232 port for sending CW, like "splitting serial ports", like "virtual ports".

Remember to check for remnents of what you uninstall. Reboot between each uninstall and test your "trigger".

How have I gone about finding a solution in the past? The following are alternative techniques you may wish to think about ....

0. Take an "image" backup of your PC to an external disk before you try any of this stuff. Standard tools in Win7 Pro.

1. I took a backup of all my data. I try hard to use only My Documents. I copied it all to an external disk, and then used the "recovery disk" supplied with my Dell system. That rebuilt my PC back to a known state, and I then moved forward with the most urgent things first, and slowly got it all working again - testing, rebooting, at each step of the way. I avoided all the "small cosmetic things" and only installed what I must have. Done that about 5 times or so on my own systems, and that of other amateurs, over many years. Has always been successful.

2. Recently, on my Win 7 system, I created a "virtual machine" using Oracle Virtual Box - its free - and selectivly installed software into it until I saw the problem. You will need a license for Windows in the virtual machine. I used Windows XP and the license from an old machine that was lying around - most Dells and Compaqs have a sticker with the license code on it. I created an initial virtual machine with Wndows XP and all the patches. That first machine I only use for updating the Windows patches. I "clone" a virtual machine, a standard process of Virtual Box, from that initial machine as I need to, and throw them away as I no longer need them. This is a safe, repeatable technique, well worth mastering. I also use it for software that will not run on Win Vista or Win 7 - that is, only runs on Win XP. I have ten or so of those machines. Ditto for any Linux software.

3. I installed a second copy of Windows on the same machine - creating a so called "dual boot system". Then, when booting the PC, one can select either the old system to continue on as before, or the new installation so one can selectively install software, testing as you go, to find the solution. This technique is a little complex - seek advice if you are unsure how to do it. Best to use separate "drives" by partitioning the hard disk appropriately. Untimately the old error prone system is abandoned, and the new one takes its place.

4. If your PC will boot from a USB drive, install a fresh system onto a USB drive and boot from it, slowly installing and testing as you go. You can continue on, or do some fault finding as and if you want. Change the boot order in the BIOS to an appropriate order. Whe the problem is found the original system has to be rebuilt.

5. The reverse of item 1. I simply uninstalled each package that I thought was relevent to my problem, testing "the trigger" at each stage as I went. While this seems like a good idea, it has its own problems. Working from bad, back to good, for me, has usually not been as successful as the reverse. Much software leaves a lot of stuff behind in the registry and in data areas on the disk. One needs to gain experience on how to purge it all. Also, during the uninstall process, questions may be asked about removing DLLs, most of which one has no idea what is, is not, using the DLL. Removing the DLL may introduce problems. I usually "keep the DLL" - the approach being that if I delete the DLL, I may introduce problems, but if I keep the DLL, the worst that can happen is a little bit of space on the disk is used up, but I do not introduce any new problems into my system.

6. I simply "hunted down" and explained each and every "error event" in the Windows 7 event log. This was a good learning experience - I found lots of software problems I did not even know were occurring. If you have never done this before , you can find the Event Viewer by - right click on Computer, and click on Manage; or click on Start, type Event Viewer, and press enter; or right click Start, click Properities and Customize the Start Menu to include Administrative Tools. The Custom Views, Administrative Events, is a good place to start. You may be very surprised at what you see in there. For example - I just looked in my Event Log to best complete this paragraph, and found six errors for "Bad Blocks" on one of my disks that occured today! This technique requires some experience in interpretation of the errors. Have a look, but resist the temptation to over react to what you see. Windows is a multi tasking, multi processing system, and lots of things just "happen". If Windows did not stop and tell you about it, its probably not to serious for the underlying Windows system as a whole.

I hope I have helped in some small way.

If you need assistance, start another thread somewhere in the forum with an appropriate topic.

Peter VK4IU
Peter VK4IU
You can help by posting images of any errors and including your Logic version.
WN4AZY
#22 Posted : Tuesday, March 26, 2013 8:41:20 PM(UTC)
admin

Rank: Administration

Groups: Administrators, Beta Testers
Posts: 3,093
Man
Location: Auburn, GA

Thanks: 997 times
Was thanked: 496 time(s) in 411 post(s)
There is a known issue of spots coming in while running reports causing errors. No solution has been found yet. I am now considering putting the reporting in a separate program.

I wasn't aware that spotting was affecting ADIF export too. I'll look into that. Sounds like the same deal.

Meantime, please disable any spot sources while running reports.

I apologize for this.

73,

Dennis WN4AZY
K1ESE
#23 Posted : Wednesday, March 27, 2013 3:28:55 PM(UTC)
Rank: Advanced Member

Groups: Registered
Posts: 69
Location: Maine

Thanks: 9 times
Was thanked: 7 time(s) in 7 post(s)
Peter -

I have no doubt that your suggestions are the way to go. Who knows what a mess my PC is after just a couple of years.

But, the list is daunting and it will take some time for me to work up the courage and tenacity to tackle it. In the meantime I see two other possibilities. One, the work Dennis is doing with the report writer may fix everything. Second, buy a new computer and start over.

For the time being I will just skip telnet while doing reports and do my ADIF work in sessions separate from Spot log and Telnet.

I appreciate your comments and will print and save them as a plan for all that ails my computer.

Thanks you for the comprehensive reply!

73 de K1ESE
John
Users browsing this topic
Guest (16)
2 Pages<12
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Powered by YAF 1.9.5.5 | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.052 seconds.