Error with autopsy 4.XX on Windows 10 64bit

Autopsy Help
#1

Hello,

As [robert.tomasik] disscused on this topics:

It seems that for some reason, in many installations of windows 10 64bits (not always) the program does not work, even reinstalling and testing with different JREs
I don’t have any third-party modules, I talk about clean installations all the time.

I have solved the visual problems like this:
setx J2D_D3D false

But it seems that there is some kind of problem with the management of the threads, the program starts normally, but all the options take many seconds or a minute to work.

I give a new case, it takes 40 seconds to open the window again, I give browse, it takes 30 seconds to open the file explorer, each folder to open, about 40 seconds. Still, it is impractical.

I have tried several different options for the Java VM. In the logs I do not see more than warnings, no errors.

I find it hard to believe that this only happens to 2 or 3 users, do you have any way to debug these errors?

Thanks!

#2

I have 2 suggestions for debugging these types of issues:

  1. Autopsy 4.17.0 has a new “Thread Dump” option under the Help menu. Grabbing a thread dump during one of these long running operations might help figure out what’s happening.
  2. Depending on your level of experience with software development/debugging you could install VisualVM (https://visualvm.github.io/) to attach to Autopsy. Using VisualVM you can also monitor memory and threads, get thread and heap dumps and profile the application.
1 Like
#3

VisualVM has been useful to me.

From what I see, every time I do an interaction with the program that takes seconds, the “swing-shell” thread goes from parked to running. Whatever is causing the delay is in that thread, since automatically, when it stops running, the “Java2D Disposer” generates the new window or drawing.

Any ideas to find out what takes you so long? While this thread is running the program blocks, so I cannot generate the “Thread Dump”

#4

You can use VisualVM to generate a thread dump.

#5

Thanks downey,

Whenever the program freezes, the thread is executing this:

"Swing-Shell" #70 daemon prio=6 os_prio=0 tid=0x00000000514c9800 nid=0x7fc runnable [0x000000006c95f000]
   java.lang.Thread.State: RUNNABLE
        at sun.awt.shell.Win32ShellFolder2.getLinkLocation(Native Method)
        at sun.awt.shell.Win32ShellFolder2.access$1400(Win32ShellFolder2.java:72)
        at sun.awt.shell.Win32ShellFolder2$11.call(Win32ShellFolder2.java:817)
        at sun.awt.shell.Win32ShellFolder2$11.call(Win32ShellFolder2.java:810)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Win32ShellFolderManager2.java:556)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - <0x00000003c58c7db8> (a java.util.concurrent.ThreadPoolExecutor$Worker)

Searching the internet I found that it is related to a “JFileChooser” problem. I don’t have network drives, so I understand that some software on my computer will be interfering with the proper functioning of this library.

I will try failsafe mode, to see if it goes well, and if so, I will close processes one by one to see if I find that it may be the cause.

#6

Is it possible that you have shortcuts to locations that no longer exist?
I had an issue in the past where it would take a really long time to browse to a case in Autopsy that was solved by deleting stale shortcuts I had lying around.

1 Like
#7

I have searched for and erased all the broken shortcuts from my drives. Now it goes much faster, although it still takes a bit of time for each action. Even so, it has gone from being unusable to being able to work with him. Thanks a lot.

If I find any other reason why that function should take so long, I’ll put it here.