GPF Zooming in large multi-channel files

So far from 2.04 on up to current release I can reproduce this issue.
THe audio files are between 1.2 and 20gb but so far the 1.2gb file is easy to reproduce with.
Open file, select “Copy” (vs editing original).

I don’t have the specifics of the offending module as I am at home and it is at the job site.

However, if you load up a large file, select a swath of audio, on ONE channel, select “SOLO”, and then zoom in on this channel it almost always detonates.

I’ll post the debug information from work tomorrow. It may be a Win10 security issue as the computers are hardened for security purposes and run data protection software.

I also wonder if it is because the antivirus is set to scan all files on access.

Anyone else using a fully STIG’d computer and having this issue?

That could very well be a problem.
Most anti-virus applications allow you to white-list specific files. For Audacity, the “.AU” data files should be white-listed. The .AUP file should not be a problem so long as it’s only being scanned once, and not every time it is modified.

So the file is a w64 file, generally 1 to 20gb in size.
Sometimes loaded across the network, but even from local machine it doesn’t matter.

Launch, load file, h it View-Tracks - fit vertically.
Highlight an area of one track, hit SOLO, and then hit zoom.
Maximize, move, or resize window and GPF occurs - not 100% of the time but on his computer with an NVideo 4000 series driver it’s pretty consistent.

I’ll be back with specific module, still trying to reproduce it on my account.

OK Tested again today.
Video adapter is NVidia Quadro M4000, although it appears the M$ driver is loaded NOT an NVidia driver so my next task will be to correct this.

Now with a 1.9gb .w64 file and audacity fully maximized hit View-Track, Fit Track Vertically.

GPF occurs.

Faulting application name: audacity.exe, version: 2.2.1.0, time stamp: 0x5a280ee8
Faulting module name: MSVCR120.dll, version: 12.0.21005.1, time stamp 0x524f7ce6
Fault offset: 0x000a7666
Faulting process id: 0x1a34
faulting application start time: 0x01d39c6a34b89a06
Faulting application path: C:\Program fi les (x86)\Audacity\audacity.exe
Report Id: 79d73d4e-272c-47f7-9b0f-215336e021a2
Faulting package full name:
Faulting package-relative application ID:

Update: updated Nvideo video driver to actual NVidea (vs M$).

Issue still occurs, moreso when dong spectrograms but will occur just by resizing.

The is sue does NOT occur on v1.3 however, going backwards allows us to work but is so not approved.

Has anyone been able to reproduce this?

Downloading 2.2.2 now will report back if it still GPF’s on Win10.

Today I went through event logs.

Audacity GPF occurs at the s ame exact point in time that me, as a user, generatesd a request for Setcbprivilege. The security log shows a failuire.

On the working domain, where we don’t have this issue, I see “Audit Success”, and on the failing domain I see “Audit failure”.

The failing domain DOES run Host Based Security System and has all of the EMET (Win10 built in) configured to the max.

Is there something audacity is doing, or requesting through .NET?

Today I renamed the MSVCR120.dll to OLD and forced audacity to use the MSVCR120.dll that was in either SysWow64 or system32. I was able to function for 5 minutes or so and never h ad a GPF until my user showed up, then it began.

Got to have resolution on this today or we have to do away with Audacity, it’s a secured environment with a lot of Security set - if we don’t have an answer we have to go back to Adobe audition or cool edit or some such program

We have found the issue. I want to reproduce it 3 times for verification. I cannot get the GPF on teh working domain, HOWEVER I do get the white screen of death for a good 60-90 seconds.

The issue resides with the Window size under spectrograms.

Go to: Edit->Preferences->Tracks-Spectrograms

Go to Window size: - set to 32768 - most narrowband and load up a mult-channel w64 file.

BOOM.

Change to 16384 and it works. Your array is either off kilter or an API to the OS to redraw the screen to “X” size is off kilter. The resolution of the spectrogram will suffer but at least we are functional, but I’m not sure if our customer will accept less.

FYI we are using the “Hanning” window type but tested all of them.

How do you submit a bug report, 2.2.2 installed has same issue.

Audacity does not use .NET.

The default is 1024.
Using “most narrowband” on a huge file will be extremely demanding and slow, so not recommended.

I’ve tested with Audacity 2.2.2 on Linux with an 8 hour track, mono, 32-bit float, 44100 Hz. The project size is about 5.4 GB. As expected, Audacity becomes very slow, even on a fast i7 with SSD, when the track is in spectrogram view with maximum window size, but no blow up here. (I don’t have a suitable Windows machine to test on).
If the array was off, then I would expect the problem to be reproducible on all platforms.

You already have done
I’ll escalate this to the QA mailing list.

Have you tried a Google search on that? It may throw up some ideas of things to test.

We’re running 2-30gb files, 16 tracks, w64 - and we need the finest resolution possible for what we do. We’ve loaded larger on Windows, it works fine for the size.

Default FFTSize is 256 (Windows) upon installation but it’s not written into the CFG file and I suspect that is the problem, probably passing a null array or something, not sure.
AFter setting to 16384 and saving, then to 32768 it’s OK - no more GPF’s.

Yes it’s slower and resizes spin like it wants to GPF but then it recovers. We’re OK with that for what we do.

Thanks for your help !! This one has a been a challenge.

Which version of Audacity?
Default for Audacity 2.2.2 is 1024, as can be seen here:

262| windowSize = gPrefs->Read(wxT("/Spectrum/FFTSize"), 1024);

and what is it that you do?