3.0.0

writhziden

Administrator, .NET/UWP Developer
Staff member
Joined
May 23, 2012
Posts
2,943
Location
Colorado
I started development of version 3.0.0 of the apps. This is going to be at least eight months of work, so do not expect it to be released before then. I will also continue to fix bugs and make additions based on requests for the current apps.

My goal is to release this roughly one year after the first release of 2.0.0, so some time in September. The interface will be much faster, and there will be minimal I/O to the hard disk to speed up the overall runtime. In a few months, I should be ready for some beta testing from those who are interested in doing so. :-}


The reason I wanted to announce this is to get some feedback from people using the apps as to what they like/dislike, big changes they would like made, etc.
 
Further suggestions:
- too many options. It needs a central interface for changing things (or a host of add-ons for folks to select?)
- option to print the user kd files that are generated by Richard's DLL

Will post more as I think of them.
 
Further suggestions:
- too many options. It needs a central interface for changing things (or a host of add-ons for folks to select?)

Which options should be primary? The two most important to me would be the kd.exe path and symbols paths.

Would you want all users to have the DRT update input as an option, or do you think that should also be an add-on?


An add-ons menu option isn't a bad idea at all. Let users go through and choose which options they want to change or work with.


- option to print the user kd files that are generated by Richard's DLL

Already working on that one. It will be one of the buttons for the html / text viewer window.
 
I think that the BSOD app should be easy/simple to setup for the beginning analyst - and that the rest of the stuff should be hidden behind a menu (it'll make it much less intimidating). When training new analysts we have to start with what we do - not with how to customize the apps (this includes the collection app and the BSOD app). I'd suggest that we have a Q&A forum for the apps so that new users can ask simple questions about how to change things. Another idea is a Simple/Advanced interface - but bury the Advanced interface in the menu so that new analysts don't find it right away (there's enough to learn about BSOD analysis without having to puzzle out the app).

I'd think that the only time you'd need to see the kd path is when installing - beyond that it could be buried in the depths of an overall menu.
Maybe hard code the installation path that results from following your directions to install the Debugging Tools - and give the option to change it at some point during the setup (with a note that no change is needed if they followed the directions).
Hard code the Symbol path in - with maybe a notification screen when doing it on installation. Changes could be buried in the overall menu also

Primary choices would be simply what files to show when complete (with the default being 98 and template). Make changing this the easiest menu item, so we can refer new analysts to it as they progress.

I'd suggest that the output be tied to the URL:
- Microsoft Answers like forums get HTML output
- Sysnative like forums get TEXT output
- unlisted forums get a choice between TEXT and HTML - and it saves the choice by URL
- maybe include a Private Run category for those helping out their friends (with a mention of it in the place where you enter it, so they know it's there)
Buried in the menu would be the choices to change them as desired.
Maybe have a confirmation dialog to save a new forum type when it's entered?

Also, I'd like to see a customizable order that the output appears in - so we can set the output in the order that we look at it (I look at stack text, 97, 98, template - only using 88 and 99 for additional info. I also have 95 so that I can easily upload (but that also means that we've gotta setup something in the DRT for analysts to upload and edit their input - if so desired)

Although I like the idea of forcing a DRT update option into it - the majority of people aren't going to want to contribute (based on past history). Maybe an opt-in screen with a note that they can choose it later on if so desired?
 
I have some ideas, I will develop these further when I have some more time.

1) I feel the GUI needs tidying a bit and simplifying. TBH, I think the way that all information is displayed to the user in overwhelming. Some settings I keep the same for many runs at a time, like symbols and formatting options. Some of these would be better hidden in a menu.

To improve the GUI, I think the app should have one main window. This window will have a "Run Now" button, an Originating Post box and an option for "New Dumps Only". These buttons should be big, bold and probably have some kind of icon next to them. This window will also have a menu bar. This menu will be used to hide some of the options. Under an options menu, it should be possible to toggle an advanced view and quick options. For the first ever click on the advanced button, it should pop up a message to alert people there are many potentially confusing settings here, do they want to continue? If they say yes, an options windows will appear with option tabs for all the options. However, the quick options will bring a small box with things like symbols (online/local), kd.exe path and username.

The GUI should also have some icons and some colour. I think the grey, whilst perfectly functional, is a little utilitarian for me and a splash of minimalistic colour would help. I do find the white boxes behind the text to be a little messy looking in the current apps.

What I don't want is 6 months down the line to look like this. Any idea what these options do??? ;)
Read More:


Some principles of a good GUI:

If I sat in front of it, knowing absolutely nothing about the program that you are having me use, could I figure out how to work it?
If yes, good GUI
If no, bad GUI

A good GUI is one that minimizes whatever learning curve happens to be there for the program's function.

A good GUI needs to be absolutely simple in its initial form. But it also needs to have a much deeper interface hidden within, that a basic user won't see much of or need, while the advanced user can find and know what to do with.

For me, a good GUI is one I shouldn't notice unless I want to. One factor for a good GUI includes good space management because (for me, at least) if something takes up too much space on a screen with no workaround, it becomes annoying


2) For new users, I think we should rename some of these files. What user will know what 99.txt, 98.txt, 88.txt will contain. The app also contains files that do the identical job - 99.txt and dumps.txt are effectively the same file. The numbered txt files are confusing, even I forget sometimes what they are, even now!

3) From the DRT side of things, I think that we NEED to get a mass driver import set-up (2013 re-write with AppGini MAY get this working). Otherwise it is useless for now. Maybe we could (in the far future) set up something to auto-submit unknown driver names to something. But that's for the far future.

4) Less pop-ups. I know I suggested pop-up options boxes before, and I know. What I mean by this is the fact some many things pop-up around the screen by themselves. For example, this is what happens at the moment:

Double clicking the exe first pops up a cmd window
First GUI loads
(Assuming user just clicks go and full GUI is on)Progress bar appears
View HTML/TXT's appears
Time appears
Cmd screen flashes on exit

None can be skipped. Would it be possible to incorporate the progress bar into the main window? So the options are above then the progress bar takes up the bottom 1/6 of the window but is always visible? Not sure how good that would work. Would also like to see all cmd flashes gone please!


All of this may sound harsh and mean but it's not. I really like the app and the work you've put in is fantastic. But these are just my thoughts on things that could be improved. Nothing personal or mean here. :)

Stephen
 
Thank you both for the input. I am currently redesigning the interface. I will have to do some research on adding color. The checkedlistboxes are probably going to be the most difficult to do this for to allow readability.

Console flashes are gone in the initial version of 3.0.0 that I have designed. There will be no console flashes; those were a side-effect of all the read/writes to the hard drive that I am now doing my best to avoid. Settings should only be saved and loaded during the setup process; there is no reason for hard drive read/writes beyond those needed for saving and loading settings and user preferences.


For the apps behavior, I am currently thinking along these lines:

  1. Have a simple first screen. Check for updates in the background and flash a screen letting the user know an update is available if there is one.

  2. On the very first run of the apps, ask the user for the kd.exe path if the path is empty and if the user chooses, let the apps find the kd.exe path for the user with a click of a button.

    Also, ask the user to opt-in or opt-out of DRT submitted material.

  3. Have a View menubar option containing a Windows option. Within the Windows option will be the following items:

    • kd.exe Path (for the current kd.exe path dropdown and browse / clear buttons)

    • Symbols Cache Behavior (for entering local and online paths and how to behave with local selected)

    • Files to Save (for the .txt files to save; please share re-naming ideas for the 88-99 .txt files)

    • Output Options (for which strings to take out of the .dmp analysis)

    • BBCode Options (for what BBCode should be included in different output files and code boxes)

    • Driver Reference Table (for the DRT username and originating post info, old driver after dates, drivers to exclude from those dates, and driver statistics)

    • Forum Formatting (header, footer, signature, template, code box formatting)


The windows will allow users to have multiple options open at once and edit them as desired, but they will be hidden within the view->Windows area for advanced users.
 
Last edited:
That sounds great, looking forward to the improved GUI! I'm always happy to beta/alpha test the app, if you wish to PM me a pre-beta version to trial, I'll be more than happy.


As I said before, I would like to see a slightly prettier, more colourful GUI. If you would like some small icons made, give me a shout. :)
 
I've created a (very quick) mock to show how I think the start window should look:
BSOD Apps mock.png
 
Out of preference, I feel the button should be at the bottom. The progress bar should be hidden until the button is clicked, at which point, the button should either disappear to be replaced by the progress bar, or the button should be changed to allow the user to cancel while the progress bar updates.

Agree? Disagree?
 
Find attached a very early version of 3.0.0; this is just the first screen.

The current version will not run any .dmps. It computes the Fibonacci of 42 and shows the progress as it does so. The progress bar functionality was taken from



The GUI is meant as an example of how I plan on having the final version work when it is run. It also is a springboard for icon ideas for Stephen. I placed the current Sysnative BSOD Apps icon for one of the buttons and a bluescreen background for the other.
 

Attachments

Let's try again, my last post was so badly mucked up by auto correct and Swype it made no sense whatsoever.

Anyway I agree that the progress bar should auto hide. My idea would be that when the user clicks run, the bar appears and the button becomes a cancel button. Then, when processing is finished, the cancel button becomes two buttons, view texts and view HTML.

I think the best thing to do regarding the GUI would be to throw some ideas around to get inspiration and to do exactly what you did, create a quick working mock of one idea. I will try the early version you posted tomorrow since I am on my nexus now. :-)

Stephen
 
I am uploading a newer version. Update checking and kd.exe path checking are now working well. The app also creates the directory structure in the background during load (this capability will be moved to an installer application later on).
 

Attachments

Last edited:
- option to print the user kd files that are generated by Richard's DLL

Just wanted you to know I have not forgotten about this for the next release of 2.X.X of the apps. I am in the midst of cleaning up the old apps to make it easier to port some of their functionality into 3.0.0, and during that cleaning up, I will add in the option to open the user kd files at the end. It may be a few days before I get the apps in a state that they can be used again.

I wanted to reply to clarify that I didn't think your request was taken as only for 3.0.0, and I know you would find this useful sooner than seven months from now. I just want to make sure all updated releases are thoroughly tested to prevent big bugs from needing fixing. :-}
 
Thanks Mike! I'd appreciate any of this that you could include in any version of the app!
How would you like to handle changes for v2xxx and requests for v3xxx? I'm not sure if I know enough to decide where I should suggest them.
I trust your judgement as to where to apply these, so feel free to include them where ever you see fit.

I'd like to suggest removing the BOLD tags from the Process name in the template.txt file. (probably a v2xxx change)
Newer analysts tend to focus on it - and it's not a very good indicator of what's at fault.
FWIW - I do use it if it's repeated in all the dumps and if it's associated with drivers that are suspect - but I'm very cautious as it can lead an analyst off-track very easily.
 
Just run the version 3 you've uploaded, really liking it so far. The icon buttons are great, although I will still go into PS for you and have a go myself :)

One thing, the buttons in the kd.exe selection window seem too large, they take up far too much room. The drop down list is also too wide, this is an issue in the current app version as well, purely cosmetic:
Screenshot - 26_01_2013 , 12_38_11 PM.png
 
Thanks Mike! I'd appreciate any of this that you could include in any version of the app!
How would you like to handle changes for v2xxx and requests for v3xxx? I'm not sure if I know enough to decide where I should suggest them.
I trust your judgement as to where to apply these, so feel free to include them where ever you see fit.

I'd like to suggest removing the BOLD tags from the Process name in the template.txt file. (probably a v2xxx change)
Newer analysts tend to focus on it - and it's not a very good indicator of what's at fault.
FWIW - I do use it if it's repeated in all the dumps and if it's associated with drivers that are suspect - but I'm very cautious as it can lead an analyst off-track very easily.

The re-design of 2.7.2 (probably going to become 2.8.0) has become a bit more complex than I had anticipated. This was my first GUI application, so I did not do a great job of organizing it so it would be easy to add/subtract items. I have learned a lot since 2.0.0.0 it would seem (including how to properly create version numbers thanks to help from my new job last week).

Anyway, the changes to the current apps may take a week. I am trying to get rid of the system() calls I made that cause the console flashes. This may impact you since I am pushing more for the GUI-based application to help users adapt better when 3.0.0 is rolled out. I know you use the console side of the apps at the moment.

Would you like me to provide a GUI and console version as separate entities?


Just run the version 3 you've uploaded, really liking it so far. The icon buttons are great, although I will still go into PS for you and have a go myself :)

One thing, the buttons in the kd.exe selection window seem too large, they take up far too much room. The drop down list is also too wide, this is an issue in the current app version as well, purely cosmetic:
View attachment 3122

The buttons I can fix; just trying to accomodate your previous request for bigger buttons. Which buttons would you prefer to be bigger and which should remain the default size?

The drop down list needs to be wide enough for the path to fit into. One thing you probably are not aware of is that the GUI is also designed for different DPI settings, so the text can get bigger causing the drop down list not to be wide enough. I try to allow for up to 150% increase in DPI. I haven't yet tested at that setting, so I may find the drop down list can be shrunk down a bit. I'll get back to you on this. :-}

Disregard the above. I just realized what you meant. You meant the dropDownWidth (the width of the list after clicking the down arrow to view all items). I have fixed this now to be 500 instead of 1024. I may reduce it further depending on the dpi settings, but 500 looks like it will be good for possible longer paths.

Thanks Stephen!
 
Last edited:
No need to make them separate - I do occasionally use the GUI, just to see what it looks like!
 
Is there anything you would like changed about the GUI progress messages?

Perhaps output them to a list format instead so you can track where the apps are at, or is the realtime progress message acceptable?
 
The current % numbers are fine for me. I'm not real concerned about the app's progress - as that's when I get stuff done.
Like this morning, I started a bunch of dumps running and took a shower while they ran.
I'll also run downstairs for a cup of coffee when they're running.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top