I marked that this happened with OOo 2.0, since it states that version in about 
box. But I just checked and the file from which I installed is called:
OOo_2.0.1_Win32Intel_install_wJRE.exe (I downloaded it on February 3, through 
torrent)

So I guess it's a version 2.0.1

It looks like I can reproduce the bug at any time. It's enough to drag this 
window for a second and my OOo freezes.

Could not reproduce on Mac (2.0.0) or Windows XP (2.0.1). On XP, dragging the
selection window behaved oddly, and left long trails before updating, but no
crash or freeze occurred. (The trails did not occur for dragging toolbars or
font color selection windows around, just the formula elements picker shown by
View->Selection while editing a formula.)

Could someone with Windows 2000 try reproducing?

Changed version to 2.0.1, changed Prio to 2.

I would also like to add that it's important that "Show windows contents while 
dragging" is enabled in Display Properities/Effects (which should be default in 
windows).

Anyway, if dragging works, then release the mouse button, and try again. Try to 
move window as quickly as you can (it even can be straight line (e.g from one 
corner of the window to another).

You can also update that this issue is with OpenOffice Math not the Word 
Processor, I just started it as a standalone program (without the word 
processor) and can do the same thing. Resizing the formula editor on the bottom 
(the screen is split into two sections), also triggers this issue.

Also (it possibly might be the same bug, since I think it's somewhere in drawing 
procedure). When I go to the formula editor by clicking on the formula, then go 
back and forth few times OOo also gets freezed (but this is much harder to 
reproduce)

As for the crashrep.exe, here is Disassembly from the Microsoft Visual Studio:
/***
* _lock_file - Lock a FILE
*
*Purpose:
*       Assert the lock for a stdio-level file
*
*Entry:
*       pf = __piob[] entry (pointer to a FILE or _FILEX)
*
*Exit:
*
*Exceptions:
*
*******************************************************************************/

void __cdecl _lock_file (
        void *pf
        )
{
        /*
         * The way the FILE (pointed to by pf) is locked depends on whether
         * it is part of _iob[] or not
         */
        if ( (pf >= (void *)_iob) && (pf <= (void *)(&_iob[_IOB_ENTRIES-1])) )
7C34F60B  mov         eax,dword ptr [esp+4] 
7C34F60F  mov         ecx,offset __iob (7C38B4E8h) 
7C34F614  cmp         eax,ecx 
7C34F616  jb          _lock_file+24h (7C34F62Fh) 
7C34F618  cmp         eax,offset __iob+260h (7C38B748h) 
7C34F61D  ja          _lock_file+24h (7C34F62Fh) 
            /*
             * FILE lies in _iob[] so the lock lies in _locktable[].
             */
            _lock( _STREAM_LOCKS + (int)((FILE *)pf - _iob) );
7C34F61F  sub         eax,ecx 
7C34F621  sar         eax,5 
7C34F624  add         eax,10h 
7C34F627  push        eax  
7C34F628  call        _lock (7C34211Ah) 
7C34F62D  pop         ecx  
}
7C34F62E  ret              
        else
            /*
             * Not part of _iob[]. Therefore, *pf is a _FILEX and the
             * lock field of the struct is an initialized critical
             * section.
             */
            EnterCriticalSection( &(((_FILEX *)pf)->lock) );
7C34F62F  add         eax,20h 
7C34F632  push        eax  
7C34F633  call        dword ptr [__imp__EnterCriticalSection@4 (7C37A038h)] 
}
7C34F639  ret              

The instruction pointer points to the "ret"

Also the value of pf is 0x0 (and probably that's why the crash happens).

Oh NVM, Actually the above isn't the OOo code. Since OOo  didn't had debugging 
symbols, I can only post the assembly code, but I doubt it will help.

Here is the stack:
 	NTDLL.DLL!77f87eeb() 	
 	msvcr71.dll!_lock_file(void * pf=0x00000000)  Line 236	C
 	msvcr71.dll!fseek(_iobuf * stream=0x00000000, long offset=0, int whence=0) 
 Line 103 + 0x8	C
>	crashrep.exe!00402001() 	

Could it be that you have a Matrox Graphics Adapter in you machine?
Matrox drivers on WinNT/Win2000 caused such problems.
If not, we'll have to further investigate. I cannot reproduce the described
problem on Win2000 and WinXP.

No, I have Sis 651 (the computer is actually Sony PCV-RX850)
Windows 2000 with SP 4.

Anyway, I'm surprised you are closing the bug just because it works on your HW,
especially that you noticed that even though it don't freezes your computer the 
window behaves oddly, and I can reproduce it nine times out of ten.

This bug is really anoying. Imagine OOo freeze for you after writing few pages, 
and after you recover your document you only see half of the page written.
You really need to hate MS Word to still trying to use OOo. Ignoring bugs like 
this you're making sure people won't be using OOo because it failed them in such 
critical way.

If you want any more details then please let me know how I can obtain them. If 
this would be unix machine, I would also provide output of strace,c and tried to 
attach gdb to the process. But I'm not really experienced with debugging 
programs on windows (especially when debugging symbols are apparently stripped).

I did not close the issue, I set it to "resolved" at first.
And this was not because it works on my HW - I tried it on dozens of other
machines with different configuration in our house. This is the reason why I
guess it is located somewhere in graphic driver stuff.
Have you reproduced it on any other Hardware (or even OS)?

I cannot do it right now, but I'll try to install OOo on another machine (maybe 
tomorrow) and check it, but since you cannot reproduce in on few machines then 
there is small chance that it will happen on another computer.
On mine it's really easy, actually I need to be really careful NOT to reproduce 
it.

But if you could reproduce, what would be the next step? Is there something that 
I could do and send you the results?

Yeah, some additional questions:
Do you have the newest driver installed for the graphics adapter?
Does the problem also occur when disabling "Show windows contents while 
dragging" in Win2000-display properties?

"Show windows contents while dragging" when it's off then of course this problem 
don't appear.

As for driver, it's from April 2005.

But since you mentioned the driver, that reminded me that I have also Mirror 
Driver from UltraVNC installed (www.ultravnc.com).
This driver is basically a fake video card that provides hooks for vnc which 
allow to get more accurate informations about displayed desktop.

I'll uninstall it and check how OOo behaves without it.

We can rule out the mirror driver from ultravnc, I disabled it (and of course 
rebooted windows) and the problem still exist.

Unfortunately, I cannot test it on other machines, but I don't see reason doing 
it. Looks like it shows only on some machines (if it would show on every 
computer, then there's no way somebody wouldn't notice the bug, it actually is 
hard to avoid it)

BTW: I also noticed similar issue when you put spreadsheet inside word, and also 
in standalone OOo Math.

All of them happen either by dragging something, or double clicking on it to 
edit.

Obviously the problem is with part of OOo that are responsible for the rendering 
of windows. If OOo is using some separate toolkit for graphic maybe the bug is 
there.

Accidentaly I found someone else who seems to have similar problems (but I guess 
that person't probably won't bother to submit bug report:
http://digg.com/software/Microsoft_says_Open_Office.
org_10_years_behind_#c1159732

So this is proof that my problem is not isolated issue.

I know you're screening the bug reports, to discard invalid ones, but this is a 
real issue and should be fixed (even if it doesn't show on each machine).

I still do not have an idea why this problem could occur. 
Does is also happen when you do the same with the Navigator or Stylist window?
In Spreadsheet and Draw/Presentation application too?

If by Stylist window you meant "Styles and Formatting" window then yes.
It also happens with navigator window.

It doesn't happen with toolbars (at least ones that I checked), also "Special 
Character" window, and "Options" window (OOo's main settings).

I guess it only happens for windows that can be opened while editing document.

This problem is also not limited only to the Writer (I saw this problem in Math 
and Calc OOo's components)

I also checked Draw (when I take "Pages" tool window (? - the one that is 
preview)  and I take it out of left side, release mouse button to make it as a 
window, and then drag it around, this also freezes the OO)
Also the Navigator in Draw has this bug.

Impress - same thing with Slide Pane
Base - I didn't found any window that would let me leave to be open and allow to 
edit the database at the same time.

Anyway I noticed also, that the bug is easier to reproduce when the window is 
bigger. Also, if I have few programs open, e.g. Writer, Calc, Math, and the bug 
shows, it blocks all of them.

So the problem is not limited to Writer, I change the component to "Framework".

Also adapted the summary of this issue.

probably duplicate to issue 60519

It might be related (it only happens with those windows that leave trail when 
dragged), but what makes that bug critical (at least for me) is that is able to 
freeze the OOo (which resulting in loss of unsaved data).
Looks like this happen when OOo cannot keep up with updating informations of the 
window (you could try to resize the window to be bigger, and perhaps trying to 
use on slower computer).

Also I encountered this problem (if it wasn't that one, then at least appeared 
the same) before 2.0 was even released (I installed a beta version).
So I doubt it was fixed in 2.0.

I am out of ideas, how this could happen...
Moving issue to framework component.

If it open, read, writes the same file (probably by different threads) as it's 
written in issue 60519, perhaps what happened was a deadlock?
I don't understand why this file needs to be written continously when windows is 
dragged or moved. If it needs to frite it, it should be done, after mouse button 
is released.

I would try to solve that bug first, and then see if it solves this issue.
This bug is not a dupe of issue 60519 but I belive they're related.

I can't reproduce it on Win2000 either so I think it also belongs to your
hardware configuration and driver versions. But I can reproduce on Windows
Vista. The  workaround is pretty simple.

*** This issue has been marked as a duplicate of 60519 ***

Dupe. The same cause and different results.

The workaround reduces chances of encountering the bug, but it's still possible 
to get freeze (e.g. when I'm writing a formula inside of a writer, and switching 
back and forth between writer, and the formula editor, once in a while it 
freezes, turning off "show windows content while dragging", of course doesn't 
affect this at all)

So please file a new issue for the 'formula problem'.

Actually this is not a dupe, although it is probably related to issue 60519.
I tried the bugfix from issue 60519, but although it fixes problem with windows 
leaving trails, the freeze still happens.

*** Issue 63603 has been marked as a duplicate of this issue. ***

TM->PL: Please have a look at this one. Maybe it´s a duplicate of  #60519, which
will be fixed in cws vcl56. Thanks in advance !

As takeda already remarks this is not duplicate; the trailing paint problem is
fixed with issue 60519, but a terminal freeze or crash is something else.
However without reproducing it locally we cannot do much.

Takeda: if you have a crashrep.exe running, then could you please submit the
stack trace and tell the stack trace id you got in return ? This way we could
get the stack trace of the crashing office, so we could at least get a hint what
is going on.

.

The peroblem is not an actual crash. It looks like Open Office goes into 
infinite loop, which I can only stop by killing the process... The loop affects 
all OpenOffice applications running (even the QuickStart icon).

In version 2.0.1 after I killed OpenOffice and restarted it, the crashrep was 
started, but when I tried to submit the information it crashed. After upgrading 
to 2.0.2 crashrep doesn't appear anymore.

I tried to run crashrep.exe, but I guess it supposed to be called by OpenOffice 
not me.
Is there any other way I coud obtain the informations for you?

I don't see this as a P2 issue: It is not a common problem that hits every user.
It can't be reproduced in general. It depends on a certain hardware and driver
configuration. Maybe issue 63842 is related.

Some new findings in in the upcomminng OOo 2.0.3?

Were there any fixes in this area?
If so, where I can download the latest build to check it if there is still an 
issue?

Issue 60519 has been fixed. Maybe this leads to some healings for this problem?!

Where I can download OOo verion with those fixes to check them?

BTW: I tried the first patch (that removes trailing windows) this didn't had 
impact on the freezes, perhaps it's related to the continous writing on HD.

I just installed OOo 2.0.3. Looks like it's a little bit harder to reproduce 
the bug now but it still exists (also the window doesn't leave trails anymore, 
but it still has somewhat odd feeling to it - perhaps it doesn't redraw as fast 
as other windows)

As usual, I opened the styles and formatting window, then dragged it (show 
windows contents while dragging, should be enabled in windows). This time I 
needed to resize the window and make it bigger to cause OOo to freeze. Also I 
belive dragging it across from e.g. top left to botttom right is more effective.

Also, I still see my HD working while I'm dragging the window. Do you think 
that freeze could be because of a dead lock?

I also noticed that this is more likely to happen when computer is busy.

Nearly one year later... I have the very same problem. Every step described by
takeda64 is true for me, too. I first experienced it with the Stylist
(Formatvorlagen as it is titled in German). Also could reproduce it with the
formula editor.

Workaround, as already described, is to disable showing window contents while
dragging. My System Windows XP Version 2002, SP 2. I tried different screen
resolutions and the same effect happened to me. My Graphic Card (if this
matters) is ATI Radeon X300 SE (128MB).

I also tried uninstall and reinstall OpenOffice (v2.1 by the way). I tried to
use the version with and without bundled JRE... no help.

This bug is really annoying. I already lost a lot of information because of such
a crash. Finally I found out the workaround which at least allows me to "feel
secure". But as stated by takeda64, I also think this is a bug which should be
fixed.

If I can help you in any way tracing this bug, please feel free to tell me how.
But I must admit I am already astonished by the detailed analysis takeda64 has
given.

Also another comment: I tried my very best to disable all running programs. Even
firewall/virus scanner (Kaspersky) but with no effect. It is only because I read
about the drive access and I know some issues with other applications
conflicting with Kaspersky when accessing simultaneously one file.

Btw: If this matter, I have a RAID system (Mirrored). Perhaps this might also
have something to do with it? Although I have the feeling it is more about the
graphics card.

Switching of 'Show window content while dragging' might help (it's somewhere in 
the desktop settings of windows). It is not related to other software. This 
problem is caused by some graphic card/driver relationships. We have had no 
chance to reproduce here.

I think constant update of views.xcu causes the problem. 
I suggest voting for http://www.openoffice.org/issues/show_bug.cgi?id=63848 .

I am running Windows Vista Business edition on a Sony Vaio VGN-SZ4MN. I can
choose between a NVidia Geforce go 7400 or onboard video, but whichever I
choose, I get the same problem that is reported here (see also issue 63842). But
with a twist. The problem only occurs when I have my backup software, carbonite
(www.carbonite.com) enabled. If I disable this software, the problem disappears.

I'd be happy to post additional diagnostic info, as long I am instructed how to
produce it (I'm quite new to Vista).

I am running OpenOffice 2.2.1.

Best--Hans

 Apparent dupe of http://qa.openoffice.org/issues/show_bug.cgi?id=63848.

*** This issue has been marked as a duplicate of 63848 ***

Closing.