|
|
Software Engineer - Red Gate Software
-
Posted Thursday, January 21, 2010 8:11 PM |
There are a few other versions of this error doing the rounds, such as: - 'svchost' has been built with an evaluation version of {smartassembly}, which has expired on Wednesday, 20 January 2010. You need to purchase a license of {smartassembly}.
- This application has been built with an evaluation version of {smartassembly}.
- Etc.
The dates vary, and aren't always reported in English, although that very much depends upon where you are, but the message probably appeared in a dialog box looking a bit like the one in Figure 1 below: Figure 1. The error dialog showing that there's trouble at mill. You've probably already worked out by now that this isn't a good thing, but first, let me assure you that you, as an end-user, most certainly do not need to buy {smartassembly}. We make it and we ought to know. The bad news is that this means that your computer is infected with some sort of malware. How do I know this? Because svchost is a part of the Windows operating system; it's a common system process and, because of this, some malware will try to disguise itself by using the process name "svchost". For various technical reasons I also know for a fact that Microsoft don't use {smartassembly} on it. If you want to know a little more, take a look at this Wikipedia article: http://en.wikipedia.org/wiki/Svchost The individual or group who wrote the malware now residing on your computer were, not surprisingly, too cheap to pay for a license for {smartassembly}, and too inept to spot that using the evaluation version would pop up this message and thus conveniently blow their cover. Hmm. why is it that criminals are besmirched with this reputation for stupidity? Oh, it's just too taxing. I might need to go for a lie down in a darkened room whilst I ruminate on this terrifying conundrum. Yes, and bring me a cup of tea, would you please? OK, end of rant. The great news here is that it should be pretty straightforward to fix, unless you've got some really exotic brand of malware, which seems unlikely given that the criminals involved couldn't even be bothered with the most basic testing before they unleashed their creation upon the world. right, sorry, I'm really going to stop that now. In most cases all you need to do is download and run a spyware removal tool. You should also make sure you've got some top quality, up to date antivirus software installed. For simplicity's sake, I'd just go for a big name like Norton, Symantec, or ESET NOD32, which is what we use (and it's been great). There are free and open source alternatives but, frankly, if you consider yourself a novice user, or you simply don't want to be bored with the details, just shell out for something big, well-known, and well-trusted. Anyway, back to the spyware removal tool. I'd recommend Spybot Search and Destory (Spybot from here in), which is free, pretty easy to use, and has always served me well. I have tried others, such as AdAware, in the past, but Spybot has always seemed to do the best job of getting rid of even the most tenacious infestations. I'm not going to give you detailed instructions on how to use Spybot to clean up your computer, partly because I'm a bit short on time right now, but mainly because the product comes with plenty of its own documentation. I will give you a quick outline of the process. But first I'm going to give you fairly detailed instructions on how to safely download the thing because, be warned, there are hacked versions and lookalikes out there that will cheerfully infect your computer with even more (probably much nastier) malware, so you need to be sure you download and install the real thing. So. The only safe place to download this tool is from the Safer Networking site at: http://www.safer-networking.org/index2.html Do not, I repeat DO NOT, download this tool from anywhere that isn't a file hosting mirror directly linked from this site. Definitely do not even think about using bittorrent or any other p2p network to download this software. If you do download it from anywhere else, as I've already said, your computer is practically guaranteed to be infected with more (probably much nastier) malware. Once you've gone to the Safer Networking homepage, just click on one of the links on the right for a page in your preferred language (figure 2). Figure 2. Choose a page in the language of your choice. Now click the Download link at the top right of the page (has an icon that looks like a 3.5 inch floppy disk above it - figure 3). Figure 3. Here are the links at the top right of the Spybot main page. Now, scroll down past the donation and "Important Information" sections, to the "Download" section. Now click the Download link for the latest version of Spybot, which should be the first link in the list (figure 4). Figure 4. Click the link to download the product itself - don't worry about the detection updates, because you can get Spybot to download them itself later. Now you need to pick a mirror using one of the "Download here" buttons on the right of the page (figure 5), but be warned: it's an unfortunate fact that most of these sites carry adverts from companies who are just about unscrupulous enough to try to trick you into downloading the wrong piece of software. It's very annoying so don't be too hasty about clicking any download links, once you're past the list of mirrors, but if you read the page content carefully you should be able to figure out which is the right link easily enough. To illustrate the problem I'm talking about, take a look at figure 6, which is a shot of the download page on the fileforum.betanews.com mirror. Figure 5. Pick a mirror site from which to download Spybot. You can pick one of the main mirrors, or scroll down the page for other mirror sites. Whichever site you choose, from this point onwards, proceed with caution. Figure 6. A typical download page for Spybot S&D on one of the mirror sites. Don't get me wrong, I'm not saying there's anything wrong with "Advanced Registry Optimizer" as a piece of software, and I'm definitely not going to even imply that it contains malware but, even if I were being charitable, I might use a phrase like "more than a little bit cheeky" to describe the fact that they've made their ad look like it contains a download button for the software you're really interested in. If I were to be less charitable, I might just get a little bit Bill Hicks about their marketing department. Don't be fooled. OK, once you click this download link the file should actually start to download. I know, a bit of a voyage, right? If there'll usually be some text on the page that says something like, "Downloading spybotsd162.exe. If your download does not start soon, click here." Give it a few moments, but if it doesn't kick off automatically you can safely click that link - watch out for even more unscrupulous ads on this page though. Now you've safely downloaded it, this is where the detailed instructions end. What you need to do next is: - Install the software you've just downloaded by running spybotsd162.exe. You'll probably get one or more security warnings, but it's fine to continue.
- Run Spybot, either by starting it directly after installation, or via the Start menu.
- Have Spybot update itself.
- Now have it make a backup of your registry just in case something goes wrong (don't worry, it probably won't - if it does you can restore the registry backup and all should be hunky dory again).
- Get it to run a scan.
- Once it's done, you can choose the problems you want to fix - generally I just choose to fix everything.
- It'll probably need you to restart your machine to fix some of the problems. Do this. You'll be asked if you're happy for Spybot to run again on start-up.
- Restart your computer.
- Spybot will run another scan and fix any other problems you choose.
- Congratulations! Your computer should be clean.
A couple of things. Firstly, if you're in any doubt about how to use Spybot, start it up, then just read the Help until you're sure. It's not difficult to use, but it's better to be safe than sorry. Secondly, Spybot is not absolutely guaranteed to find and fix all problems, so you might want somebody who knows what they're doing to take a look at your PC anyway. Hopefully you're now spyware free, and the {smartassembly} evaluation version message has disappeared.
|
-
Posted Wednesday, January 20, 2010 3:11 PM |
By far the most exciting of these releases is the .NET Reflector Pro Beta, but Alex has already blogged extensively about this at http://www.simple-talk.com/community/blogs/alex/archive/2010/01/20/87639.aspx, so to get the low-down on this release, take a look at his excellent post. We have also released ANTS Memory Profiler 5.2 this morning. This is a recommended upgrade for all ANTS Memory Profiler 5.x users, which includes a number of important bug fixes: - Fixed infinite progress hang when taking a snapshot whilst profiling Sharepoint.
- Now warns about object reference fix-up problem when running application with Server GC; this has been raised as a bug on Microsoft Connect at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=483764.
- Fixed CouldNotMapFileException when profiling an application with more than 46,000,000 objects on a 32-bit system.
- Fixed problem where Dispose tracking only worked on debug, non-optimized builds.
- Fixed problem where cross-assembly references can cause a crash when multiple AppDomains are used.
- Fixed intermittent GDI+ errors caused by summary view graphs.
- Fixed server error from "What do I look for?" help link at bottom of class graph.
- Corrected support forum URL on Getting Started form.
You can get the latest version of ANTS Memory Profiler, as always, from: http://www.red-gate.com/products/ants_memory_profiler/index.htm
|
-
Posted Thursday, January 14, 2010 1:19 PM |
Earlier today we released {smartassembly} 4.2. You can download it from: http://www.smartassembly.com/download/index.aspx This release, which has been available as a private build for a while, contains support for .NET 4.0 beta 2, and XNA 3.1. We've also made a few changes to the smartassembly.com website, mainly to try to make it easier for you to find product documentation. The most notable is the addition of links on the support homepage to all of the PDF documentation for the product: http://www.smartassembly.com/support/index.aspx The most recent data I've received from our support team shows that a lot of people were struggling to find the information they needed about the product on the website, so I hope that in the short term this will help. In the longer term, we'll be bringing {smartassembly} onto the main Red Gate website, and fully integrating the business into Red Gate. This includes all documentation and support functions. Whilst we're still pulling together the project team for this, work has already begun, and we aim to have the process completed in Q2 this year. As part of this release, we're also aiming to fix a large number of the bugs that have been reported by you over the past four months, and improve the usability of the product based on the results of the tests we've been doing. If you're already a {smartassembly} customer you should find the transition relatively painless, and we'll obviously keep you abreast of developments in the meantime. In the meantime, if you'd be willing to talk to us about your experience with the product, please email me directly at bart.read@red-gate.com.
|
-
Posted Wednesday, January 06, 2010 3:22 PM |
End of life is a bit of a touchy subject, and is often either brushed under the carpet, or dealt with via the "stealth withdrawal" mechanism which, not surprisingly, often doesn't go down well with customers. [Confession time: yes, we have occasionally done the latter, and yes, this includes a couple of products that I've worked on. I know, I know, I'm a bad person, but I'm not going to let this happen again.] So in the interests of doing a rather better job than we've done in the past I wanted to give you an outline of our plans regarding support for .NET 1.0 and .NET 1.1 in our toolset, both of which are now rather long in the tooth. Whilst I'm not into dropping support for things just because they're "old" - for example, I've no intention of dropping support for Windows XP - increasingly we are finding that there's no way to support new functionality on these versions of the .NET platform. To illustrate, in ANTS Memory Profiler 5, where this has been most problematic so far, dispose tracking, comparisons, and many of the filters only work when profiling an application running on CLR 2.0 or later. Almost inevitably one day we're going to get to the point where, in order to support some new function, we'll break the .NET 1.0 and .NET 1.1 support. Times change, technologies move on, like it or not, it's going to happen. But it shouldn't happen abruptly, and it shouldn't come as a surprise to anyone. There's also the fact that very few people are targetting .NET 1.x these days, and that number is getting smaller by the day, so we'd be expending an awful lot of effort for very little gain to continue support indefinitely. That's cold, hard commercial reality for you but if you're one of those people, don't panic - keep reading, because we have a plan for that as well. So, here's what we're going to do. - .NET 1.x support will be deprecated in ANTS Performance Profiler once version 6 is released in Q2 (roughly) this year.
- It will be deprecated in ANTS Memory Profiler with the 5.2 release, which will be released later this month.
- We have no immediate plans to deprecate support in {smartassembly}, or Exception Hunter for the foreseeable future.
- .NET Reflector will continue to support assemblies compiled under .NET 1.x, and will happily run on any framework version from 1.1 onwards.
- Debugging of assemblies compiled with .NET 1.x will be supported by .NET Reflector Pro into the future, although you should be aware that you can only use .NET Reflector Pro in Visual Studio 2005 and later, and hence it needs .NET 2.0 or later to run.
- Note that both profilers, along with {smartassembly}, will only run under .NET 2.0 or later already.
For those of you who aren't clear about what I mean by "deprecated", it's simply this: the support will still be in the product, but you should be aware that we may remove it from a future release, so you should consider not relying on it being there indefinitely. In our case it also means that new functionality will often not support .NET 1.x. So what will happen when we eventually do remove support? Well, there are a couple of things I'd say about this: - Most .NET 1.x applications will run unmodified quite happily on CLR 2.0.
- If you absolutely require .NET 1.x compatibility we'll still be able to supply you with earlier versions of the profilers that do work with .NET 1.x, although you won't be able to download or purchase them via our website.
Since I've already mentioned that we're not dropping venerable old Windows XP, you might ask why, and the answer is simply that most of you are probably still running it, and it's likely to continue to be popular for some time to come. We'll probably review the situation again in a couple of years but at the moment we've no plans to either deprecate or drop support, so breathe easy. We're all still running on XP whilst we wait for Windows 7 to be rolled out across the company. I should say that some of the new functionality in ANTS Performance Profiler 6 will only work fully on Windows Vista or later because it uses APIs which are only available in Vista or later, but that constitutes a small part of the whole. Hopefully that's all reasonably reassuring, but if you do have questions or comments, please post them below.
|
-
Posted Monday, January 04, 2010 5:27 PM |
2009 was a busy year for us: yet another complete rewrite with ANTS Memory Profiler 5, a new profiling mode in ANTS Performance Profiler 5, the {smartassembly} acquisition, most of the work done for .NET Reflector 6 and .NET Reflector Pro, which allows you to debug into third party code just as if it were your own - we're now into heavy pre-release bug-fixing - and starting work on ANTS Performance Profiler 6, including a brand new, and very fast, sampling mode. On top of this we released a new version of Exception Hunter, including a brand new source code view showing exactly where exceptions are thrown, and an option to only include documented exceptions. We also kicked out several patch releases of the performance profiler which we used to make significant improvements to IIS and ASP.NET profiling support - our next big focus related to this is Sharepoint, so look for this in ANTS Performance Profiler 6. Both .NET Reflector 6/.NET Reflector Pro, and ANTS Performance Profiler 6 are already available to try in the form of early access builds. If you haven't taken the time to look at them yet I'd highly recommend you do so. You can get them from: http://bit.ly/5UveA7 and http://bit.ly/8G5FYQ respectively. .NET Reflector will be released late in February, with ANTS Performance Profiler 6 following later in the year. We want to include .NET 4.0 and Silverlight 4 support with ANTS Performance Profiler 6, so we're rather tied to Microsoft's release schedule unfortunately. One of the other great things about this release is that we'll finally offer support for attaching the profiler to a running process in sampling mode, which is often a must for profiling production systems, and is something a lot of you have been rightly clamouring for. Going back to .NET Reflector 6, we intend to continue supporting the Mono runtime, however we've run into "a bit of a glitch", which has temporarily derailed our plans. I won't go into details here, because I've talked about this on the Mono forums at http://bit.ly/7sbB77, but the short version is that until we've fixed this problem with v6 we will continue to provide 5.1.x builds that run on Mono. It's all a bit of a pain, but not the end of the world. In the meantime, let me apologise for any hassle it might cause you. In addition, we're starting work on a new major release of {smartassembly} which will pull the product more in line with the rest of our product range, allow us to fix a raft of problems reported by customers, and include support for the final release of .NET 4.0. As with our other tools we'll be conducting remote usability trials of new builds so, if you're interested, please drop an email to usability@red-gate.com. ANTS Memory Profiler 5 has gone down a storm, and we're already looking at how we can improve the tool further to make it even easier to track down memory problems in .NET code. Please keep the feedback coming - we really do need it to make our tools solve the problems that you encounter on a day to day basis. Please post any comments you have on the forum at http://bit.ly/8hOjyT. I said at the beginning that 2009 was busy, but I think 2010 will be busier, with major releases of .NET Reflector, {smartassembly}, and ANTS Performance Profiler on the cards just within the first few months of the year. Finally, and on a slightly tangential note, Red Gate is currently hiring: if you're a talented software developer looking for a new job and you'd like to work for an exciting company developing cool software then we're looking for you. Take a look here to find out more: http://bit.ly/5SL6g7. Happy New Year!
|
-
Posted Friday, October 02, 2009 4:20 PM |
You may have noticed that the analyzer doesn't show anything useful for enum values. If you analyze the enum itself you can see, for example, where it is used (see figure 1), however, if you choose one of the values, all the nodes in the analyzer will be empty (see figure 2). Figure 1. Analyzer showing usages of the System.Data.SqlDbType enum. Figure 2. Result of analyzing the Decimal value of the System.Data.SqlDbType enum. Note that both the "Used By" and "Assigned By" nodes are empty. This happens because the enum values themselves don't appear in the compiled IL, only the numeric values of the underlying type, by default System.Int32, to which they map. For example, say you have this enum: public enum CustomColor { Red = 0, Purple = 1, Orange = 2 } And you use it in a switch statement like this: switch ( myCustomColor ) { case Red: ... break; case Purple: ... break; case Orange: ... break; default: ... break; }
When you compile this code the "Red", "Purple", and "Orange" values don't end up in the IL: just 0, 1, and 2. So, when you decompile with .NET Reflector you end up with: switch ( myCustomColor ) { case 0: ... break; case 1: ... break; case 2: ... break; default: ... break; }
It's then impossible to find all usages of, for example, "Orange", because the information is lost from the compiled code, and if we mapped to the numeric value, and then searched for uses of that. well, you can imagine how many false positives there might be. There are a couple of things we could consider doing about this: - Disable the Analyze option for enum values.
- Do some sort of inference based on the type of the value in the switch statement.
I think (1) sounds like a sensible short term, whilst (2) might be something we would consider introducing in a future version of .NET Reflector. Note though that there are circumstances where (2) might not work correctly, and so could result in spurious, or missing, results in the analyzer. It's also worth pointing out that having the PDB files for the assembly won't make any difference since they do not store this information.
|
-
Posted Friday, October 02, 2009 3:18 PM |
Yes, you can. There are two possible approaches, both of which utilise add-ins to .NET Reflector. The first, assuming that you've lost the source code, is to decompile back to source, edit the source code you need to change, and then recompile. If this is what you want to do, please refer to the information at: http://www.simple-talk.com/community/blogs/bart/archive/2009/07/30/74199.aspx Bear in mind that .NET Reflector's decompilation support isn't perfect-see http://www.simple-talk.com/community/blogs/bart/archive/2009/07/30/74203.aspx for more information-so you'll probably have to do some, and possibly quite a lot of, spade work to get the code to recompile successfully. The second, and possibly better, approach is to use Sebastien Lebreton's Reflexil add-in, which you can find at: http://sebastien.lebreton.free.fr/reflexil/ Reflexil supports direct editing of the IL, as well as injection of C# and VB code on the fly.
|
-
Posted Thursday, September 03, 2009 5:36 PM |
Our hosting provider is moving, yes physically moving, the server that hosts the .NET Reflector download site between facilities. This means that it could be unavailable for up to 6 hours. Last time they moved one of our servers it was actually only down for 2 hours, but they prefer to give us the worst case scenario for obvious reasons. The downtime, depending on where you are, will be between: - 0000 on Sunday 6th - 0600 on Sunday 6th (BST)
- 1900 on Saturday 5th - 0100 on Sunday 6th (EDT)
- 1600 on Saturday 5h - 2200 on Saturday 5th (PDT)
I'm assured that this move is absolutely necessary, and I apologise for any inconvenience it might cause you.
|
-
Posted Friday, August 21, 2009 7:06 PM |
-
Posted Friday, August 21, 2009 3:12 PM |
We're asked about this fairly regularly, so I thought it was about time I posted up our position on it here. There are two main reasons: - The auto-update means that we can roll out improvements to all users. So far, that's meant the occasional bug fix, but for some time we've been working on some big improvements. These include new functionality, along with fixes for a lot of the bug reports we've received. We aim to get this out early next year, and everybody will receive the benefit of this update.
- Support: having only one version in the wild makes supporting .NET Reflector, which is extremely popular, a much more manageable task. This really goes back to the first reason: if we fix a problem everybody gets the fix and hopefully everybody's happy.
We are always looking at making things better though so, if you've had a problem with the auto-update, please let us know about it and we'll see what we can do to improve matters. On a side-note, we are occasionally asked what we use for the auto-update function, and whether people can use this in their own applications. Unfortunately the answer to this is no, because it's our own proprietary code, but if you are after this kind of functionality, I'd recommend Microsoft's own ClickOnce deployment, which ships with the .NET framework: http://msdn.microsoft.com/en-us/library/wh45kb66.aspx
|
-
Posted Wednesday, August 19, 2009 2:44 PM |
Many methods in .NET code are overloaded. For example, the PipeStream method on the StreamPiper class, in figure 1, has four overloads. Figure 1. The .NET Reflector browser, showing overloads of the PipeStream method on the StreamPiper class. So, when you find one of these methods used in the decompiled source code, how do you know which overload is being called, other than by guessing, perhaps by looking at the number of parameters passed to the method? Fortunately, this is fairly straightforward: just hover your mouse cursor over the method invocation, and .NET Reflector will pop up a tooltip telling you which overload is being called, as shown in figure 2, below. Figure 2. Decompiled source in the Disassembler pane with a tooltip showing which overload of the PipeStream method is being called. This example shows C#, however this also works for other languages. Occasionally people ask us if we can further annotate invocations to overloaded methods, however there are a couple of problems with this. The first is that, unless we annotated with comments, there would be no chance of the code compiling, which would be a problem if you were trying to recover it. The second follows on from the first: any annotations would seriously interfere with the readability of the generated source code, simply because of the number of overloaded methods in most .NET code.
|
-
Posted Wednesday, August 19, 2009 12:47 PM |
I see this question come up from time to time in the .NET Reflector mailbox, so I'm going to make a stab at a sensible answer that's more than just a some marketing fluff piece, because there are alternatives, although it's debatable how realistic they are. You basically have three options: - Create a debug build of the assembly you're interested in using the generated source code.
- Use the Deblector add-in from within .NET Reflector.
- Wait for .NET Reflector Pro, or at least an early access build of the product-should be available in the next month or two-and use that instead.
If you've been following my previous posts, you'll be aware that it's possible to decompile an entire assembly, and even generate a Visual Studio project for the decompiled source: http://www.simple-talk.com/community/blogs/bart/archive/2009/07/30/74199.aspx http://www.simple-talk.com/community/blogs/bart/archive/2009/07/31/74222.aspx So, at least in theory, you should be able to fire up Visual Studio and build a debug version of the assembly you've decompiled (option 1). There are a couple of reasons this probably won't work, which I'll talk about below, but let's assume for a minute it does work; what you then need to do is substitute any references to that assembly in your project with references to the debug version. Then, when you're debugging, you can set break points in the generated code and debug it, just as you would any other source code. OK, sounds good, so why is it unlikely to work? - .NET Reflector may not be able to decompile everything in the assembly, or may generate some source code that isn't quite correct, or won't recompile. Many of the reasons for this are discussed at http://www.simple-talk.com/community/blogs/bart/archive/2009/07/30/74203.aspx. Thus, you'll get build errors in Visual Studio when you try to recompile the assembly, unless the code in the original assembly is relatively simple and was compiled from an OO/imperative language, such as C# or VB.
- If the assembly you've decompiled is used by other assemblies that you haven't decompiled, they probably won't work with the debug build you've created, even assuming it recompiles successfully. To get around this you'll need to decompile all of the other assemblies that reference the assembly you're interested in, and then recompile them against the debug build you've created. The chances of this working are minimal.
So, option 1 is probably out. Option 2 involves using Deblector to debug the assembly from within .NET Reflector itself. You can find Deblector here: http://www.codeplex.com/deblector The downside here is that documentation is sketchy and there hasn't been any activity on the project since early 2008, which makes me think it's probably dead. Option 3, which isn't really an option yet, if I'm completely honest, is to use .NET Reflector Pro. If all goes well, I'd like to see an early access build out there that you can use within the next month or two. As any of you who have used our early access builds before will know, they're generally pretty usable, albeit with bugs in them, but I'd say this is probably your best option in the longer term. EDIT: .NET Reflector Pro is now in beta. Download instructions are available here: http://www.red-gate.com/messageboard/viewforum.php?f=109.
|
-
Posted Tuesday, August 11, 2009 6:37 PM |
-
Posted Tuesday, August 11, 2009 6:33 PM |
To find out which add-ins you have installed, open up .NET Reflector, and click on the View > Add-Ins item on the main menu. The Add-Ins dialog box should pop up, showing you a list of the installed add-ins (see figure 1). Figure 1. The .NET Reflector Add-Ins dialog, showing two installed add-ins. The Add-Ins dialog allows you to install and remove add-ins. For installation instructions, along with an extensive list of the available add-ins, please refer to Andrew Clarke's article at: http://www.simple-talk.com/dotnet/.net-tools/using-.net-reflector-add-ins/
|
-
Posted Tuesday, August 11, 2009 6:28 PM |
|
|