Problems w Irfanview ? It disappears.

On 9/18/2010 2:37 AM, Ofnuts wrote:
On 18/09/2010 07:08, Gordon Freeman wrote:
wrote:
Supposedly this is not Irfanview's fault, it's my
system, so I wonder if anybody else has had it?
...
I go to Save As, and the Irfanview window disappears.
Gone. All lost. It seems worse after heavy editing,

Since something is causing the Irfanview process to die, you might
consider
the possibility of a hardware problem, especially faulty memory (RAM).

That would cause other software to die...

Not necessarily.

On 18/09/2010 10:27, J. Clarke wrote:
On 9/18/2010 2:37 AM, Ofnuts wrote:
On 18/09/2010 07:08, Gordon Freeman wrote:
wrote:
Supposedly this is not Irfanview's fault, it's my
system, so I wonder if anybody else has had it?
...
I go to Save As, and the Irfanview window disappears.
Gone. All lost. It seems worse after heavy editing,

Since something is causing the Irfanview process to die, you might
consider
the possibility of a hardware problem, especially faulty memory (RAM).

That would cause other software to die...

Not necessarily.


In these days of virtual memory, you can't tell in advance on what real
addresses your code and data end up. In this case IrfanView always dies
doing the same thing, and a failing memory would cause crashes more at
random, depending on how the code and data are mapped to real memory.

And if the same failing memory is used by other software I doubt they
will survive for long. Flip one bit in a pointer (or in any address in
your return stack) and you are likely to address something that isn't in
your allocated memory space.

This said, although IrfanView is photo-related, this topic would have
been better suited to one of the comp.* groups.

--
Bertrand

On 9/18/2010 5:04 AM, Ofnuts wrote:
On 18/09/2010 10:27, J. Clarke wrote:
On 9/18/2010 2:37 AM, Ofnuts wrote:
On 18/09/2010 07:08, Gordon Freeman wrote:
wrote:
Supposedly this is not Irfanview's fault, it's my
system, so I wonder if anybody else has had it?
...
I go to Save As, and the Irfanview window disappears.
Gone. All lost. It seems worse after heavy editing,

Since something is causing the Irfanview process to die, you might
consider
the possibility of a hardware problem, especially faulty memory (RAM).

That would cause other software to die...

Not necessarily.


In these days of virtual memory, you can't tell in advance on what real
addresses your code and data end up. In this case IrfanView always dies
doing the same thing,

Where does he say that it "always dies doing the same thing"?

and a failing memory would cause crashes more at
random, depending on how the code and data are mapped to real memory.

Or not, as the case may be.

And if the same failing memory is used by other software I doubt they
will survive for long. Flip one bit in a pointer (or in any address in
your return stack) and you are likely to address something that isn't in
your allocated memory space.

Depends on what specifically is happening.

Generalizing that "this is the only program that shows identifiable
symptoms therefore the problem cannot be hardware" is simply wrong-headed.

This said, although IrfanView is photo-related, this topic would have
been better suited to one of the comp.* groups.

"Crash!" wrote in message
om...


Supposedly this is not Irfanview's fault, it's my
system, so I wonder if anybody else has had it?

The way I most often use Irfan is:
I'll paste an image from Clipboard over an Irfanview
image that came from any handy file icon.
I'll edit that image, often cropping, cutting,
pasting, adding text, sharpening and reduce color
depth.

I go to Save As, and the Irfanview window disappears.
Gone. All lost. It seems worse after heavy editing,
and worse in Save As than Save. It might happen
about 1/3 of the time that I save after editing.

Anybody else had that problem?

Thanks!


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


Have you uninstalled it, rebooted and installed it again?

--
N

On 18/09/2010 11:47, J. Clarke wrote:


Generalizing that "this is the only program that shows identifiable
symptoms therefore the problem cannot be hardware" is simply wrong-headed.

I'd have agreed with that in the 70s, maybe even the 80s. But not these
days, unless the software does something very hardware-specific, like
using a specific peripheral or a common component in a very specific way
(video card) but it doesn't seem to be the case here.
--
Bertrand

On 9/18/2010 8:10 AM, Ofnuts wrote:
On 18/09/2010 11:47, J. Clarke wrote:


Generalizing that "this is the only program that shows identifiable
symptoms therefore the problem cannot be hardware" is simply
wrong-headed.

I'd have agreed with that in the 70s, maybe even the 80s. But not these
days, unless the software does something very hardware-specific, like
using a specific peripheral or a common component in a very specific way
(video card) but it doesn't seem to be the case here.

On very recent machines I've seen such problems go away when memory was
replaced. The notion that a virtual memory system always puts things in
different places is a gross oversimplification.

Ofnuts wrote:

And if the same failing memory is used by other software I doubt they
will survive for long. Flip one bit in a pointer (or in any address in
your return stack) and you are likely to address something that isn't in
your allocated memory space.

Do your programs consist mostly of pointers instead of doing real
work or having real data?

Memtest86 ist the right tool, just in case, and it should be
run overnight. This will find memory problems or exclude
them from the list of problems.

-Wolfgang

N wrote:

Have you uninstalled it, rebooted and installed it again?

The 'R's of Windows management:
Retry, Restart, Reboot, Reinstall, Redhat.

-Wolfgang

--
Windows is like a small child. It needs a regular nap (reboot) every so often.
It also needs to regularly get a good rest (full shutdown and reboot). There
are several reasons why it will throw a temper tantrum. And, of course, like
a child, there doesn't HAVE to be a reason, just if it feels like it.

On 18/09/2010 17:19, Wolfgang Weisselberg wrote:

Do your programs consist mostly of pointers instead of doing real
work or having real data?

Yes. And those of most anyone else, except those doing heavy numerical
processing. Don't look at your code, look at the libraries you use.

Memtest86 ist the right tool, just in case, and it should be
run overnight. This will find memory problems or exclude
them from the list of problems.



--
Bertrand

On 9/18/2010 12:18 PM, Ofnuts wrote:
On 18/09/2010 17:19, Wolfgang Weisselberg wrote:

Do your programs consist mostly of pointers instead of doing real
work or having real data?

Yes. And those of most anyone else, except those doing heavy numerical
processing. Don't look at your code, look at the libraries you use.

Memtest86 ist the right tool, just in case, and it should be
run overnight. This will find memory problems or exclude
them from the list of problems.

Not necessarily.

I remember running a memory tester on a machine for three weeks once and
then the first time the application ran it gave the same parity error it
always gave on that machine. Sometimes memory errors are
prior-state-dependent and a test program can't always find those.