Sometimes you DO need to invent the wheels

There is a well-known approach that states ‘there is no need to re-invent the wheel’. In other words, it means that if you decided to implement some functionality in your program, you should googlize to make sure it’s not implemented by other people and if it is then just use it and don’t waste the time. The time seems to be very important in software development cycle. Sure.

Nice. But in fact there are some problems.

In any operating system to reuse some functionality you need some interfaces to be exposed to communicate with them. Let’s say your program should load some library and communicate with it via exported functions. It gives your application the flexibility – you may load/unload the code you want to run any time, the only one problem is that: in most cases you cannot control the code.

I will omit the scenario when the library that contains needed for your program functionality is developed by the developer in your company. I want to tell about the scenario when your application uses different components from different vendors.

So let’s say you have the video rendering application. The application takes the video file as the input and produces the screenshots as the output. The application uses COM to communicate with Microsoft DirectShow (DS) 9.0.

This is what I told above: application uses DS interfaces to process the video file. It does not even know what components implement those interfaces – your application really does not care about it… And this causes a lot of problems(all problems refer to using inproc server):

– when your application process video using 3rd party codecs you cannot control memory allocation/dealloaction by the codec

– the 3rd pary component code have an access to your application memory: thus it may cause heap corruption, etc

– exotic situations (like described below)

My exotic case was connected with strange MessageBox I saw when debugging my application. The following call to IFilterGraph->Connect(…) showed message box like this:

The output window contains list of interesting strings:

'console.exe': Loaded 'D:\Program Files\Common Files\Ahead\DSFilter\NeVideo.ax', Binary was not built with debug information.
'console.exe': Loaded 'D:\WINDOWS\system32\ddraw.dll', No symbols loaded.
'console.exe': Loaded 'D:\WINDOWS\system32\dciman32.dll', No symbols loaded.
First-chance exception at 0x04eca8ed in console.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x04ec9ed6 in console.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x04eca0e7 in console.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x04eca225 in console.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x04ec7e76 in console.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x04ec7fcb in console.exe: 0xC0000005: Access violation writing location 0x00000000.

Looking at ‘D:\Program Files\Common Files\Ahead\DSFilter\NeVideo.ax’ sections:

answers the question: the dll file is packed using AsProtect protector – the typical behavour of protector is to add ‘adata’ section. The message box I saw was the protection action of AsProtect. It detects my Visual Studio debugger as WinIce/SoftIce (I don’t have none of them installed) and terminate my process.

Now I back to the topic of my post. If somebody invented the wheel for you, make sure it’s safe. In this situation I can only deinstall Nero codecs and never install them again…

1,194 views

Leave a Reply

Your email address will not be published. Required fields are marked *

Identify yourself * Time limit is exhausted. Please reload CAPTCHA.