Severity: Info
Summary
ServiceValidationRules.Validate checks service name length but not its character set. The Windows SCM rejects names containing \ or / (and treats leading/trailing whitespace inconsistently). When an invalid name is submitted, the user sees a generic Win32 error surfaced from CreateService / ChangeServiceConfig rather than a friendly validation message.
File and lines
src/Servy.Core/Validators/ServiceValidationRules.cs, lines 42–50:
if (string.IsNullOrWhiteSpace(dto.Name) || string.IsNullOrWhiteSpace(dto.ExecutablePath))
{
result.Errors.Add(Strings.Msg_ValidationError);
return result; // Stop early for missing vital fields
}
// Length Bounds
if (dto.Name.Length > AppConfig.MaxServiceNameLength)
result.Warnings.Add(string.Format(Strings.Msg_ServiceNameLengthReached, AppConfig.MaxServiceNameLength));
Only presence and length are checked. Characters like \, /, and embedded whitespace are accepted at validation time but rejected later by the SCM.
For comparison, ServiceDependenciesValidator (see the change in #324) already enforces a character regex on dependency names — the same rigor would be appropriate for the primary service name.
Explanation
Windows service names must:
- Not contain
\ or /
- Be ≤ 256 characters (already enforced here)
- Not be empty or whitespace-only (already enforced via
IsNullOrWhiteSpace)
Per Microsoft docs on CreateService, the service name is subject to the same restrictions as an SCM key name: forward slash and backslash are forbidden, and the name is not case-sensitive. Submitting My/Service or path\svc triggers a Win32 error 123 (ERROR_INVALID_NAME) that bubbles up as a raw error message instead of a validation failure the caller can surface nicely.
Suggested fix
Add an explicit character-set check alongside the existing length/presence checks:
// Basic Requirements
if (string.IsNullOrWhiteSpace(dto.Name) || string.IsNullOrWhiteSpace(dto.ExecutablePath))
{
result.Errors.Add(Strings.Msg_ValidationError);
return result;
}
if (dto.Name.IndexOfAny(new[] { '\', '/' }) >= 0)
result.Errors.Add(Strings.Msg_InvalidServiceName); // new Strings resource
Then add a matching Msg_InvalidServiceName entry to the Servy.Core Strings resources (English + translations).
Severity: Info
Summary
ServiceValidationRules.Validatechecks service name length but not its character set. The Windows SCM rejects names containing\or/(and treats leading/trailing whitespace inconsistently). When an invalid name is submitted, the user sees a generic Win32 error surfaced fromCreateService/ChangeServiceConfigrather than a friendly validation message.File and lines
src/Servy.Core/Validators/ServiceValidationRules.cs, lines 42–50:Only presence and length are checked. Characters like
\,/, and embedded whitespace are accepted at validation time but rejected later by the SCM.For comparison,
ServiceDependenciesValidator(see the change in #324) already enforces a character regex on dependency names — the same rigor would be appropriate for the primary service name.Explanation
Windows service names must:
\or/IsNullOrWhiteSpace)Per Microsoft docs on
CreateService, the service name is subject to the same restrictions as an SCM key name: forward slash and backslash are forbidden, and the name is not case-sensitive. SubmittingMy/Serviceorpath\svctriggers a Win32 error 123 (ERROR_INVALID_NAME) that bubbles up as a raw error message instead of a validation failure the caller can surface nicely.Suggested fix
Add an explicit character-set check alongside the existing length/presence checks:
Then add a matching
Msg_InvalidServiceNameentry to the Servy.Core Strings resources (English + translations).