I think many of you a familiar with function SetWindowsHookEx. It is quite useful function, and we use it in a lot of places in our software. But recently I found interesting issue: if exception is raised in hook function, then Windows will terminate your application with status code 0x C000041D STATUS_FATAL_USER_CALLBACK_EXCEPTION. But there is one caveat: if you run application from debugger, Windows will not terminate application and will just suppress exception. So, if you have encounter that exception as developer, you may think that everything is correct, but when end user will run your application – application will crash.

I work primarily with languages that have native support for exceptions and it feels kind of wrong. There is

I did some research on this topic and I decided to share my findings.

First reason: Standards

On most 32 bits systems type short is 2 bytes long, type int is 4 bytes long. But there are also standards.

According to C90 standard:

sizeof(short) <= sizeof(int) <= sizeof(long)

According to C99 standard:

sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)

If int size will 8 bytes long then there will be no type that it is 4 bytes long because due to standard, long type should be at least the same size as int type. It is possible to make short type 4 bytes long

About 5 years ago, we moved our main application to 64-bit. And we quickly discovered one pattern that was everywhere and in many different languages: converting pointers to 4-byte integers and back. Here is one of such examples is C++ code:

void* address;
(void*)(((unsigned int)address) + 1)

It was working in 32-bit systems because pointer and integers are exactly the same size and there is no data loss. But during transition to 64 bits, decision was made to keep integer 4 bytes in size. At least on systems I know of.

As result, if you run code above for address that is greater than max int, you will get invalid address. But until address is in first

Previous part is here. This post will explain, how to restart your web site at specific intervals without returning errors to clients. You can scroll to solution, if you are no interested in my thoughts and to see what I try.

Thoughts and research

As I mentioned in this post, I decided to restart my web site periodically to avoid out of memory issue. And I would like to mention that it wasn’t easy to do. Obviously, restarting web site is super simple and all you need is to restart its service. But that means that your web site will be unavailable for some time. Depending on size of the web site, we are talking about seconds or

Some time ago, I wrote series of posts on how to run .NET Core app on AWS Lightsail Linux instance. Everything worked nice but sometimes, about once per month my web site stopped responding. And I cannot connect to my instance at all to diagnose that issue. All I can do is just restart my AWS instance. At the beginning I thought it could be AWS issue, or perhaps some issues in .NET. I updated everything I can, but problem persists. And when it happened last time, I decided to check kernel logs and I found this:

Feb 10 07:31:18 ip-1-2-3-4 kernel: [1512878.216567] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/www.example.com.service,task=dotnet,pid=511,uid=1001
Feb 10 07:31:18 ip-1-2-3-4 kernel: [1512878.216597] Out of memory: Killed process 511 (dotnet) total-vm:3007440kB, anon-rss:105260kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:712kB oom_score_adj:0
Feb 10 07:31:18 ip-1-2-3-4 kernel: [1512878.241642] oom_reaper: reaped process 511 (dotnet), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

  •   Posted in:
  • .NET

Recently I was asked to check why one of our applications crashes when it calls CreateNamedPipe function. Everything works fine in the x64 version, but the x86 version crashes. There are no differences in the code between x86 and x64 and they compiled the same.

Let’s see how CreateNamedPipe defined in our code:

[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
static extern SafePipeHandle CreateNamedPipe(string lpName, uint dwOpenMode,
    uint dwPipeMode, uint nMaxInstances, uint nOutBufferSize, uint nInBufferSize,
    uint nDefaultTimeOut, SECURITY_ATTRIBUTES securityAttributes);

and here is how it called:

SafePipeHandle safeHandle = CreateNamedPipe(
                cPipeAccessDuplex |
                cPipeTypeMessage |
                nOutBufferSize: 0,
                nInBufferSize: 0,

Everything looks correct. I checked flags, compared them with

Creating and publishing packages in GitHub

Creating tokens

Go https://github.com/settings/tokens and create 2 tokens. One with a write:packages scope and one with a read:packages scope for consumption. The first token I called Package Publisher and the second one Package Reader. Save them somewhere safe.

Creating NuGet config file

Create nuget.config file. Something like this:

<?xml version="1.0" encoding="utf-8"?>
        <add key="github" value="https://nuget.pkg.github.com/<YourOrganizationName>/index.json" />

Instead of "github" you can use any other description you like. It just a name of the entry. Then you need to put this file in the same directory as solution for your package and for every solution that will

I would like to start with a side note. Everybody should use secure connections for everything. Somebody could say: “But I don’t have anything important there, why should I bother?”. And I can tell you why you should bother. You see, most of the time you will start with something not important, but it will grow very quickly and in a very short time, there will be a lot of important stuff. But then, because it contains important stuff, it will be much harder to change because it “just works”. Usually, everybody starts to care about security only when it is too late. So, it is much easier to do it right from the beginning.

I wrote a small application

I have a .NET application that contains about 70 files. Application contains mostly .NET assemblies, but there are a few native .dlls as well. This application is deployed on multiple machines. Native .dlls never change and we do not build them when the application is compiled.

Usually, I deploy the application by wiping the old version (after I do a backup) and copy the new version into an empty directory. But here is a dilemma. If I copy native .dlls as part of the build process, it increases build time, as well as copy time. And because they never change it looks like a waste of time. But if I will skip them, then I cannot wipe a directory and