When using the mouse to drag and select a range on the griddesktop control, my application will stop responding and then crash after selecting an arbitrary amount (usually ~200 cells).
I am unable to recreate the bug if I run from Visual Studio or I have any type of debugger attached, however when the app is built in release mode and run as a standalone app it will almost definitely crash.
I have created a dummy app which loads an excel spreadsheet, and nothing else to demonstrate the bug. I am using 23.6, but I have tested this on all releases from 23.6 to 24.2 and the all behave in the same way.
See the attached image as a demonstration.
33588 test app example 23.6.gif (774.7 KB)
AsposeExcelBug.zip
@JamTheMan,
Thank you for providing the template Excel file, screenshot, and sample project.
I have tested/run your application’s EXE (from the “…\bin\Release” folder) with the resource file and it works fine. I selected a few big ranges (as per you screenshot) and it works fine. I did not encounter any exceptions or crashing issues. I apologize, but could you please provide guidance on how we can use/test your application to reproduce the issue? Additionally, please share details about your environment (OS and version, VS.NET version, .NET framework version, etc.). We will evaluate and look into your issue soon.
Thanks for the quick response.
I have had a lot of issues testing and trying to debug this particular problem, and for a while I wasn’t sure there was a bug, but I have tested this on my machine and 2 different VMs and they all experience the same issue. Sometimes it doesn’t happen immediately, sometime you need to try selecting and if after say 3 or 4 hundred cells are selected and the problem hasn’t been hit, scroll to the top and start from the top cell and drag and select again. There is nothing to do but repeat until it happens, but it does happen and on Friday it was hitting me almost every time I tried without fail, today it has been a bit less repeatable, but I have still managed to recreate it.
I have never been able to recreate the issue when running from within Visual Studio or with any debugger or crash dump collectors attached.
I have created a crash dump after the crash, I’m not sure if its of any use but here is a link:
AsposeExcelBug crash dump.zip
Environment.
All machines using .NET 4.8.09037
VM 1 Windows 10 Version 22H2 19045.4046 4 CPU cores
VM2 Windows 10 Version 22H2 19045.3570 2 CPU cores
Laptop: Windows 10 22H2, Visual Studio 2022 Professional V17.8.4 6 cores (12 threads)
If you need any additional information for your evaluation, please let me know.
Hi,
I also saw the crash on a Hyper V VM 4gb, 22H2 as above, .NET 4.8.0937.
I saw it crash around 210 rows 4 out of 4 times I tried 100% reproduction ratio.
I also witnessed, that, as JamTheMan said, enabling a debug diagnostics crash dump collector rule actually stopped the crash from happening. Even when I set the environment variable for no debug heap, it still would not crash, which is a thing I’ve done before for such situations.
I also noticed that inside the VM if I configured the EXE to be in Windows 8 Compatibility mode on the properties page, that the crash no longer happened.
Interestingly I can’t make it crash on my super-powerful laptop hosting the VM.
@JamTheMan @GMiddleton
Thanks for providing more details about the issue. We will do more test on it to see whether we can reproduce and figure the issue out. We will give feedback soon.
Good luck.
If you have the PDBs for that Aspose.Cells.Dll, maybe @JamTheMan 's crash dump is the golden ticket to get a call stack, but because Aspose DLLs are obfuscated it’ll be nonsense at first, I’m guessing you have to de-obfuscate the symbols?
If you can’t recreate and need to try experimental EXEs out, I’m willing to help.
@JamTheMan, @GMiddleton,
We require thorough evaluation of the issue you described using your resource files. We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): CELLSNET-55237
Once we have an update on it, we will let you know.
1 Like
@GMiddleton @JamTheMan
finally we can reproduce it, we will fix it soon.
@peter.zhou incredible! Well done. I know that must have been tiresome to keep scrolling and retrying!
We appreciate the effort - So being a geek I’d love to know - was it a threading/locking issue? UI Invoke issue? Event subscription overload? Tell us more when you can.
@GMiddleton,
Yes, it might be a little tedious to reproduce the issue you have mentioned, but we were able to reproduce it.
Please spare us a little time to evaluate and analyze it in detail. We will then provide more details and the actual cause of the issue. Also, we will try to figure it out soon.
@GMiddleton
It is strange that we cannot reproduce it in debug mode. I guess it is related with too much repaint. However, if I put the paint request in a queue, using thread call, the scrolling affect is not acceptable. We still need to investigate more.
@peter.zhou we experienced the same issue.
Yes, we found that in release build with PDBs, attaching a debugger would stop the problem happening.
When we used Microsoft’s Debug Diag Crash dump Collector - it would not crash.
The author of WinDbg suggested to me that setting the environment variable _NO_DEBUG_HEAP may help capture the crash, but it did not. General Environment Variables - Windows drivers | Microsoft Learn
@JamTheMan did capture a .DMP file by getting the crash to happen without the debugger, then using Windows Task Manager to create a process DUMP, which could then be used in WinDbg etc.
Good luck!
@GMiddleton,
Thanks for providing further details and your findings.
We will be looking into the details of the issue and get back to you soon.
@GMiddleton
Thanks for your help.
Finally we find the root cause is not related with too much repaint. We now use another way to do the range select auto scroll action. I can see the issue does not occur anymore. We will publish the fix in the incoming new release v24.3 version.
1 Like
@peter.zhou Congrats - our team is very impressed with the speed of your support and resolution on an issue that was hard to reproduce AND debug. If you need us to try an experimental DLL on different OS before release we are willing to help.
@GMiddleton,
Thank you for the compliments, but we try to resolve user issues quickly to the best of our ability. We appreciate the offer, and we will investigate if we can provide you with a fixed version. However, our upcoming release v24.3 is in the works, and it is possible that the new version will be published in this week. Once the new release is available, we will notify you.
1 Like
The issues you have found earlier (filed as CELLSNET-55237) have been fixed in this update. This message was posted using Bugs notification tool by johnson.shi