I'm moving again... back to my original blog: http://randtalk.blogspot.com/
I don't think anyone follows this blog anyway so....
Saturday, December 13, 2014
Tuesday, December 9, 2014
Getting Started with WinDbg
Recently one of my applications started freezing up on our Production servers. It was impossible to figure out what was going on from the logs and reviewing the code seemed to only show that such behavior should be impossible. So I took a crash dump and used WinDbg to analyze. Turned out it seemed to be caused by one of the libraries our origen used and that was recently upgraded. Simple, right?
...Not quite, I skipped the part where it took me more than 2 days to figure out how to properly take the dump and get it running inside WinDbg.
So to save other people the trouble, here what you need to now and how to get started.
First, you'll need to get the program which comes in two versions, 32 and 64-bit. The one you need depends on the version of the program you are debugging, not the operating system it is on.
On a 64-bit Windows, you can tell this at by looking at the process in Task Manager. A 32-bit application with have *32 next to the process name in the Details tab.
The WinDbg installers though are part of the Windows SDK package which is downloadable on the Microsoft site.
However, the web installer wants to install the entire SDK but really you just need WinDbg. So...
You can download the ISO here and after mounting it, there should be a folder with the WinDbg installers, thus avoiding the need to install the SDK.
This is for the Windows 7 SDK but for other versions there should be something similar; just search around for it.
OK, so let's say you need to debug a 32-bit process running on 64-bit Windows 7. However, you will doing the analysis on another machine (running a different version of .NET).
So first, you need to take the process dump. To do this, I recommend you use SysInternal's Process Explorer (procexp.exe). If you Google it, you will easily find it (will put a link up eventually)
This avoids the issue of having to run the 32-bit version of Task Manager because it's too stupid figure the correct format of the dump file in the 64-bit program. ProcExp avoids the whole issue because it's smart :) Just right-click on the process and select Dump --> Full Dump
I've never tried mini dumps, but more is probably better.
No once you have this file, you need to copy it somehow to your debugging machine. Also you need to copy 2 files from the machine:
Now start the version of WinDbg based on the application's bit-ness, in our case 32-bit.
Then, drag the dump file into the program. This will load it.
Now configure the Symbols Path using File->Symbols Path, and enter:
SRV*{local path}*http://msdl.microsoft.com/download/symbols
The {local path} should be a folder; it does not have to exist.
Now you need to load the process PC's .NET environment, specifically the two DLL files.
Execute .load {full path to file} to load the two DLLs.
Then type !analyze which will begin analyzing the dump.
If you get an error saying something like the CLR version does not match, most likely it is because it automatically loaded this machine's environment which overrides the custom set ones.
If you run .chain it should show the first entry as something related to .NET. Also make sure the two DLLs you loaded are under it.
Type .unload to remove the entry and analyze again. This should not have any issues now.
And now you're all set up!
Here's a few cheat sheets to get you started:
http://windbg.info/doc/1-common-cmds.html
http://theartofdev.com/windbg-cheat-sheet/
Also here's the link to the SOSEX extension which adds some pretty useful features, in my opinion.
http://www.stevestechspot.com/
You can load it in a similar manner as the other DLLs.
Pictures to come at a later date... or never.
This avoids the issue of having to run the 32-bit version of Task Manager because it's too stupid figure the correct format of the dump file in the 64-bit program. ProcExp avoids the whole issue because it's smart :) Just right-click on the process and select Dump --> Full Dump
I've never tried mini dumps, but more is probably better.
No once you have this file, you need to copy it somehow to your debugging machine. Also you need to copy 2 files from the machine:
- SOS.dll
- mscordacwks.dll
- C:\Windows\Microsoft.NET\Framework64\{version}
- C:\Windows\Microsoft.NET\Framework\{version}
Now start the version of WinDbg based on the application's bit-ness, in our case 32-bit.
Then, drag the dump file into the program. This will load it.
Now configure the Symbols Path using File->Symbols Path, and enter:
SRV*{local path}*http://msdl.microsoft.com/download/symbols
The {local path} should be a folder; it does not have to exist.
Now you need to load the process PC's .NET environment, specifically the two DLL files.
Execute .load {full path to file} to load the two DLLs.
Then type !analyze which will begin analyzing the dump.
If you get an error saying something like the CLR version does not match, most likely it is because it automatically loaded this machine's environment which overrides the custom set ones.
If you run .chain it should show the first entry as something related to .NET. Also make sure the two DLLs you loaded are under it.
Type .unload to remove the entry and analyze again. This should not have any issues now.
And now you're all set up!
Here's a few cheat sheets to get you started:
http://windbg.info/doc/1-common-cmds.html
http://theartofdev.com/windbg-cheat-sheet/
Also here's the link to the SOSEX extension which adds some pretty useful features, in my opinion.
http://www.stevestechspot.com/
You can load it in a similar manner as the other DLLs.
Pictures to come at a later date... or never.
Keeping It Simple
Complexity is a great demotivator... For example:
Complexity: You have a 40 minute manual build/deployment process where a single error will set you back to the beginning? You're not going to doing builds too often and when you do, it will contain a large number of changes which if any issues arise will be some times be impossible to figure out what the root cause.
Solution? Automate the deployment process as much as possible. (NAnt, Ant, write some utility programs)
Complexity: You keep your shopping, to-do list, or a large amount of important information in your head. I guarantee you will forgot things and drive other people mad.
Solution? Write things down and organize them, because if you can't find it, it's the same as not writing it down... which leads to...
Complexity: You keep things everywhere in an unorganized manner such that it takes much longer than necessary to find things when you need them.
Solution? Find or develop some organization system with fixed rules which significantly narrows the area you need to look in.
Complexity: You have way too many blogs such that it you spend so much time trying to decide which one to post in that you don't post anything at all (Raises hand)
Solution? Well so far I decided to just pick one and move all the other content here. I'm still figuring it out...
Complexity: You have a 40 minute manual build/deployment process where a single error will set you back to the beginning? You're not going to doing builds too often and when you do, it will contain a large number of changes which if any issues arise will be some times be impossible to figure out what the root cause.
Solution? Automate the deployment process as much as possible. (NAnt, Ant, write some utility programs)
Complexity: You keep your shopping, to-do list, or a large amount of important information in your head. I guarantee you will forgot things and drive other people mad.
Solution? Write things down and organize them, because if you can't find it, it's the same as not writing it down... which leads to...
Complexity: You keep things everywhere in an unorganized manner such that it takes much longer than necessary to find things when you need them.
Solution? Find or develop some organization system with fixed rules which significantly narrows the area you need to look in.
Complexity: You have way too many blogs such that it you spend so much time trying to decide which one to post in that you don't post anything at all (Raises hand)
Solution? Well so far I decided to just pick one and move all the other content here. I'm still figuring it out...
Sunday, November 9, 2014
How to Publish Existing Projects to GitHub
I had spent an hour or more trying to publish my existing projects to GitHub the first time doing it, so this is for anyone that wants to avoid the trouble and is a completely new to GitHub and Git.
First you will need the git utilities which can be found here: http://git-scm.com/
I assumed you are using Windows and installed it to the PATH as well; otherwise you will need to use the Git Shell.
You also need the GitHub app, which you should know where to get (hint: github.com).
This will be the easiest way to do it.
You can just use git shell but you'll need to manually register the machine on GitHub and use the git's add and commit calls. Also the GitHub's some nice additional features like code comparison and a GUI (I know GUIs sometimes get a bad rap from power users but sometimes they actually make things easier and shell)
The steps below are assume you:
I sometimes have projects with multiple child components each with their own .csproj, but the solution puts it all together and they really should be treated as 1 project. So for those, I would use the first choice.
In the folder, type and execute
This creates a new local repository in the folder. Note the repo will be named the same as the folder it is created in.
In Explorer, go to the folder containing the project folder (1 level higher than the folder in which you created the repo)
Drag the folder into GitHub which will then list the files in the folder and sub folders.
You will see the files that are added, most likely you don't want the build files like bin/*, obj/*. You do this by creating a .gitignore file but you can use GitHub to do it for you:
With the new repo selected, on the top right, you should see a widget icon which when clicked it will display a menu. Click on the "Repository Settings..." option.
You should now see 2 columns, and large icons that say "Create ..."
Click on them and they will create the default files. I've never touched the Attributes but you may need to edit "Ignored files" if you have some custom files you want ignored.
Now once, this is done, exit the settings and the Files To Commit list should update appropriately.
When you have reviewed all the files, commit it to master by first filling out at least the Summary field (when that is filled out, the Commit button will be enabled).
You have now added the files to your local repository. You need to click "Publish Repository" for the project to be created on GitHub.
Then, the button will turn into "Sync" and you need to click this for your files to be added to GitHub.
Again, "Sync" actually copies the files (not Commit, not Publish Repository).
For subsequent commits, you follow a similar process, "Commit to master" will commit the changes to the local repo, "Sync" will send them to GitHub.
First you will need the git utilities which can be found here: http://git-scm.com/
I assumed you are using Windows and installed it to the PATH as well; otherwise you will need to use the Git Shell.
You also need the GitHub app, which you should know where to get (hint: github.com).
This will be the easiest way to do it.
You can just use git shell but you'll need to manually register the machine on GitHub and use the git's add and commit calls. Also the GitHub's some nice additional features like code comparison and a GUI (I know GUIs sometimes get a bad rap from power users but sometimes they actually make things easier and shell)
The steps below are assume you:
- have the above set up, obviously
- have an existing C# project, but any project would be similar and you can probably figure it out
- creating a new GitHub repo for the project
I sometimes have projects with multiple child components each with their own .csproj, but the solution puts it all together and they really should be treated as 1 project. So for those, I would use the first choice.
In the folder, type and execute
git init In Explorer, go to the folder containing the project folder (1 level higher than the folder in which you created the repo)
Drag the folder into GitHub which will then list the files in the folder and sub folders.
You will see the files that are added, most likely you don't want the build files like bin/*, obj/*. You do this by creating a .gitignore file but you can use GitHub to do it for you:
With the new repo selected, on the top right, you should see a widget icon which when clicked it will display a menu. Click on the "Repository Settings..." option.
Click on them and they will create the default files. I've never touched the Attributes but you may need to edit "Ignored files" if you have some custom files you want ignored.
You can add individual files with their exact name, or folders which need to be in the format: <folder name>/
You can also use * in the as a wildcard so "myFile*" would exclude any file beginning with "myFile"
"myFolder*/" would match any folder beginning with "myFolder", and all its subfolders as well.
You can also use * in the as a wildcard so "myFile*" would exclude any file beginning with "myFile"
"myFolder*/" would match any folder beginning with "myFolder", and all its subfolders as well.
Now once, this is done, exit the settings and the Files To Commit list should update appropriately.
When you have reviewed all the files, commit it to master by first filling out at least the Summary field (when that is filled out, the Commit button will be enabled).
You have now added the files to your local repository. You need to click "Publish Repository" for the project to be created on GitHub.
Then, the button will turn into "Sync" and you need to click this for your files to be added to GitHub.
Again, "Sync" actually copies the files (not Commit, not Publish Repository).
For subsequent commits, you follow a similar process, "Commit to master" will commit the changes to the local repo, "Sync" will send them to GitHub.
Bulk Rename Utility 1.0
Recently wanted to rename a bunch of similar video files and thought it would be nice to do a bit of programming (pretty much all weekend... but it was fun) to do it. The result is Bulk Rename Utility.
The program allows you to rename a bunch of files at once based on Filters (or rules).
Currently there are two types of filters but for the most part you only need RegexFilter anyway. TrimFilter I guess is more just to prove that multiple filters work :)
The RegexFilter searches the name for the parts that match the regular expression in SearchFor and replaces with the text in ReplaceWith. To delete the matches entirely, just leave ReplaceWith empty.
Also, if you have files loaded, it will use the first file's name as the default Preview text.
The TrimFilter trims a single character from the beginning and end of the name, not very exciting I know.
Note that filters are run in order, so if you had:
Original String: Hello World
Filter 1: World => Apple
Filter 2: Apple => Orange
The result would be "Hello Orange". And if you flipped the order, it would be "Hello Apple"
The program also allows you to save the filters so that it can be used again on other files.
Finally, you can remove multiple files from the list at once by using CTRL to select multiple items and clicking "Remove Selected".
Download: https://drive.google.com/folderview?id=0BwHjtARwf-GFV0ZidHplMF85TFE&usp=sharing
GitHub: https://github.com/allanx2000/BulkRename
Also all applications are built for .NET 4.0 Client Profile, unless otherwise stated. I've only tested it on Windows 8 x64... because I'm too lazy to install a x86 VM but it should work as it is compiled targeting Any CPU.
The program allows you to rename a bunch of files at once based on Filters (or rules).
Currently there are two types of filters but for the most part you only need RegexFilter anyway. TrimFilter I guess is more just to prove that multiple filters work :)
The RegexFilter searches the name for the parts that match the regular expression in SearchFor and replaces with the text in ReplaceWith. To delete the matches entirely, just leave ReplaceWith empty.
Also, if you have files loaded, it will use the first file's name as the default Preview text.
The TrimFilter trims a single character from the beginning and end of the name, not very exciting I know.
Note that filters are run in order, so if you had:
Original String: Hello World
Filter 1: World => Apple
Filter 2: Apple => Orange
The result would be "Hello Orange". And if you flipped the order, it would be "Hello Apple"
The program also allows you to save the filters so that it can be used again on other files.
Finally, you can remove multiple files from the list at once by using CTRL to select multiple items and clicking "Remove Selected".
Download: https://drive.google.com/folderview?id=0BwHjtARwf-GFV0ZidHplMF85TFE&usp=sharing
GitHub: https://github.com/allanx2000/BulkRename
Also all applications are built for .NET 4.0 Client Profile, unless otherwise stated. I've only tested it on Windows 8 x64... because I'm too lazy to install a x86 VM but it should work as it is compiled targeting Any CPU.
Monday, November 3, 2014
I Write Programs For Fun... Mostly
I am a self-taught programmer, been doing it since I was 7 and now I am in my mid-20s so that's like 15+ years of experience... kind of, programming as a 7 year old is not the same as on-the-job experience. But then again there are lot's of things that you don't pick up from school or the job like good coding habits and how to approach new problems or learn new skills, the latter is probably a very good skill to have.
Anyway, this blog isn't really about what I do for my job, and to be quite frank, my work isn't terribly interesting. I code a lot on the side just for fun or to solve some problem I see over and over again.
So I figured instead of collecting digital dust on my hard drive, I might as well put them out there.
Some of the programs aren't too polished but it'll get there when I have some time and interest to spare. I tend to code in bursts and whenever I think of something new to add and get around to adding it.
I will set up a GitHub... eventually... probably this weekend and share the code. A lot of the code needs to be documented... since I haven't gotten around to it yet so that's another reason I'm kind of holding it back.
If you really want, you can go ahead and use ILSpy to decompile the code in the meantime.
Anyway, this blog isn't really about what I do for my job, and to be quite frank, my work isn't terribly interesting. I code a lot on the side just for fun or to solve some problem I see over and over again.
So I figured instead of collecting digital dust on my hard drive, I might as well put them out there.
Some of the programs aren't too polished but it'll get there when I have some time and interest to spare. I tend to code in bursts and whenever I think of something new to add and get around to adding it.
I will set up a GitHub... eventually... probably this weekend and share the code. A lot of the code needs to be documented... since I haven't gotten around to it yet so that's another reason I'm kind of holding it back.
If you really want, you can go ahead and use ILSpy to decompile the code in the meantime.
Subscribe to:
Posts (Atom)